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Abstract 


This document discusses and defines a number of tests that may be 


used to describe the performance characteristics of ATM 


(Asynchronous 


Transfer Mode) based switching devices. In addition to defining the 
tests this document also describes specific formats for reporting the 
results of the tests. 
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1. Introduction 


This document defines a specific set of tests that vendors can use to 
measure and report the performance characteristics of ATM network 
devices. The results of these tests will provide the user comparable 
data from different vendors with which to evaluate these devices. 

The methods defined in this memo are based on RFC 2544 "Benchmarking 
Methodology for Network Interconnect Devices". 


The document "Terminology for ATM Benchmarking" (RFC 2761), defines 


many of the terms that are used in this document. The terminology 
document should be consulted before attempting to make use of this 
document. 


The BMWG produces two major classes of documents: Benchmarking 
Terminology documents and Benchmarking Methodology documents. The 
Terminology documents present the benchmarks and other related terms. 
The Methodology documents define the procedures required to collect 
the benchmarks cited in the corresponding Terminology documents. 
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2. Background 
2.1. Test Device Requirements 


This document is based on the requirement that a test device is 
available. The test device can either be off the shelf or can be 
easily built with current technologies. The test device must have a 
transmitting and receiving port for the interface type under test. 
The test device must be configured to transmit test PDUs and to 
analyze received PDUs. The test device should be able to transmit 
and analyze received data at the same time. 


2.2. Systems Under Test (SUTs) 


There are a number of tests described in this document that do not 
apply to each SUT. Vendors should perform all of the tests that can 
be supported by a specific product type. It will take some time to 
perform all of the recommended tests under all of the recommended 
conditions. 


2.3. Test Result Evaluation 


Performing all of the tests in this document will result in a great 
deal of data. The applicability of this data to the evaluation of a 
particular SUT will depend on its expected use and the configuration 
of the network in which it will be used. For example, the time 
required by a switch to provide ILMI services will not be a pertinent 
measurement in a network that does not use the ILMI protocol, such as 
an ATM WAN. Evaluating data relevant to a particular network 
installation may require considerable experience, which may not be 
readily available. Finally, test selection and evaluation of test 
results must be done with an understanding of generally accepted 
testing practices regarding repeatability, variance and the 
statistical significance of a small numbers of trials. 


2.4. Requirements 


In this document, the words that are used to define the significance 
of each particular requirement are capitalized. These words are: 


x "MUST" This word, or the words "REQUIRED" and "SHALL" mean that 
the item is an absolute requirement of the specification. 


* "SHOULD" This word or the adjective "RECOMMENDED" means that there 
may exist valid reasons in particular circumstances to ignore this 
item, but the full implications should be understood and the case 
carefully weighed before choosing a different course. 
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* "MAY" This word or the adjective "OPTIONAL" means that this item 
is truly optional. One vendor may choose to include the item 
because a particular marketplace requires it or because it 
enhances the product, for example; another vendor may omit the 
same item. 


An implementation is not compliant if it fails to satisfy one or more 
of the MUST requirements for the protocols it implements. An 
implementation that satisfies all the MUST and all the SHOULD 
requirements for its protocols is said to be "unconditionally 
compliant"; one that satisfies all the MUST requirements but not all 
the SHOULD requirements for its protocols is said to be 
"conditionally compliant". 


2.5. Test Configurations for SONET 
The test device can be connected to the SUT in a variety of 


configurations depending on the test point. The following 
configurations will be used for the tests described in this document. 


1) Uni-directional connection: The test devices transmit port 
(labeled Tx) is connected to the SUT receive port (labeled Rx). 
The SUTs transmit port is connected to the test device receive 
port (see Figure 1). In this configuration, the test device can 
verify that all transmitted packets are acknowledged correctly. 
Note that this configuration does not verify internal system 
functions, but verifies one port on the SUT. 


| 
| Test  Rx|<-------------- |Tx SUT | 


Figure 1 


2) Bi-directional connection: The test devices first transmit port is 
connected to the SUTs first receive port. The SUTs first transmit 
port is connected to the test devices first receive port. The 
test devices second transmit port is connected to the SUTs second 
receive port. The SUTs second transmit port is connected to the 
test devices second receive port (see Figure 2). In this 
configuration, the test device can determine if all of the 
transmitted packets were received and forwarded correctly. Note 
that this configuration does verify internal system functions, 
since it verifies two ports on the SUT. 
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4+------------- + 4+------------- + 
| Test Tx | SSS SSeS eS >|Rx 
Device Rx|<-------------- TX SUT 
Tx Rx Tx Rx 
+------------- + +------------- + 
| ^ | ^ 
| | | | 
| +------------------------ + | 
Figure 2 


3) Uni-directional passthrough connection: The test devices first 
transmit port is connected to the SUT1 receive port. The SUT1 
transmit port is connected to the test devices first receive port. 
The test devices second transmit port is connected to the SUT2 
receive port. The SUT2 transmit port is connected to the test 
devices second receive port (see Figure 3). In this 
configuration, the test device can determine if all of the packets 
transmitted by SUT1 were correctly acknowledged by SUT2. Note 
that this configuration does not verify internal system functions, 
but verifies one port on each SUT. 


4+------------- + 4+------------- + 4+------------- + 
Tx | ---------- >|Rx Tx | ---------- >|Rx 
| SUT1 Rx|<---------- |Tx Test Rx|<---------- |Tx  SUT2 | 
| Device 
4+------------- + 4+------------- + 4+------------- + 
Figure 3 


2.6. SUT Configuration 


The SUT MUST be configured as described in the SUT users guide. 
Specifically, it is expected that all of the supported protocols will 
be configured and enabled. It is expected that all of the tests will 
be run without changing the configuration or setup of the SUT in any 
way other than that required to do the specific test. For example, 
it is not acceptable to disable all but one transport protocol when 
testing the throughput of that protocol. If PNNI or BISUP is used to 
initiate switched virtual connections (SVCs), the SUT configuration 
SHOULD include the normally recommended routing update intervals and 
keep alive frequency. The specific version of the software and the 
exact SUT configuration, including what functions are disabled and 
used during the tests MUST be included as part of the report of the 
results. 
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2.7. Frame formats 


The formats of the test IP PDUs to use for TCP/IP and UPC/IP over ATM 
are shown in Appendix C: Test Frame Formats. Note that these IP PDUs 
are in accordance with RFC 2225. These exact IP PDU formats SHOULD 
be used in the tests described in this document for this 
protocol/media combination. These IP PDUs will be used as a template 
for testing other protocol/media combinations. The specific formats 
that are used to define the test IP PDUs for a particular test series 
MUST be included in the report of the results. 


2.8. Frame sizes 


All of the described tests SHOULD be performed using a number of IP 
PDU sizes. Specifically, the sizes SHOULD include the maximum and 
minimum legitimate sizes for the protocol under test on the media 
under test and enough sizes in between to be able to get a full 
characterization of the SUT performance. Except where noted, at 
least five IP PDU sizes SHOULD be tested for each test condition. 


Theoretically the minimum size UDP Echo request IP PDU would consist 
of an IP header (minimum length 20 octets), a UDP header (8 octets), 
AAL5 trailer (8 octets) and an LLC/SNAP code point header (8 octets); 
therefore, the minimum size PDU will fit into one ATM cell. The 
theoretical maximum IP PDU size is determined by the size of the 
length field in the IP header. In almost all cases the actual 
maximum and minimum sizes are determined by the limitations of the 
media. In the case of ATM, the maximum IP PDU size SHOULD be the ATM 
MTU size, which is 9180 octets. 


In theory it would be ideal to distribute the IP PDU sizes in a way 
that would evenly distribute the theoretical IP PDU rates. These 
recommendations incorporate this theory but specify IP PDU sizes, 
which are easy to understand and remember. In addition, many of the 
same IP PDU sizes are specified on each of the media types to allow 
for easy performance comparisons. 


Note: The inclusion of an unrealistically small IP PDU size on some 
of the media types (i.e., with little or no space for data) is to 
help characterize the per-IP PDU processing overhead of the SUT. 

The IP PDU sizes that will be used are: 

44, 64, 128, 256, 1024, 1518, 2048, 4472, 9180 

The minimum size IP PDU for UDP on ATM is 44 octets, the minimum size 


of 44 is recommended to allow direct comparison to token ring 
performance. The IP PDU size of 4472 is recommended instead of the 
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theoretical FDDI maximum size of 4500 octets in order to permit the 
same type of comparison. An IP (i.e., not UDP) IP PDU may be used in 
addition if a higher data rate is desired, in which case the minimum 
IP PDU size is 28 octets. 


2.9. Verifying received IP PDUs 


The test equipment SHOULD discard any IP PDUs received during a test 
run that are not actual forwarded test IP PDUs. For example, keep- 
alive and routing update IP PDUs SHOULD NOT be included in the count 
of received IP PDUs. In any case, the test equipment SHOULD verify 
the length of the received IP PDUs and check that they match the 
expected length. 


Preferably, the test equipment SHOULD include sequence numbers in the 
transmitted IP PDUs and check for these numbers on the received IP 
PDUs. If this is done, the reported results SHOULD include, in 
addition to the number of IP PDUs dropped, the number of IP PDUs that 
were received out of order, the number of duplicate IP PDUs received 
and the number of gaps in the received IP PDU numbering sequence. 
This functionality is required for some of the described tests. 


2.10. Modifiers 


It is useful to characterize the SUTs performance under a number of 
conditions. Some of these conditions are noted below. The reported 
results SHOULD include as many of these conditions as the test 
equipment is able to generate. The suite of tests SHOULD be run 
first without any modifying conditions, then repeated under each of 
the modifying conditions separately. To preserve the ability to 
compare the results of these tests, any IP PDUs that are required to 
generate the modifying conditions (excluding management queries) will 
be included in the same data stream as that of the normal test IP 
PDUs and in place of one of the test IP PDUs. They MUST not be 
supplied to the SUT on a separate network port. 


2.10.1. Management IP PDUs 


Most ATM data networks now make use of ILMI, signaling and OAM. In 
many environments, there can be a number of management stations 
sending queries to the same SUT at the same time. 


Management queries MUST be made in accordance with the applicable 
specification, e.g., ILMI sysUpTime getNext requests will be made in 
accordance with ILMI 4.0. The response to the query MUST be verified 
by the test equipment. Note that, for each management protocol in 
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use, this requires that the test equipment implement the associated 
protocol state machine. One example of the specific query IP PDU 
(ICMP) that should be used is shown in Appendix C. 


2.10.2. Routing update IP PDUs 


The processing of PNNI updates could have a significant impact on the 
ability of a switch to forward cells and complete calls. If PNNI is 
configured on the SUT, one routing update MUST be transmitted before 
the first test IP PDU is transmitted during the trial. The test 
SHOULD verify that the SUT has properly processed the routing update. 


PNNI routing update IP PDUs SHOULD be sent at the rate specified in 
Appendix B. Appendix C defines one routing update PDU for the TCP/IP 
over ATM example. The routing updates are designed to change the 
routing on a number of networks that are not involved in the 
forwarding of the test data. The first IP PDU sets the routing table 
state to "A", the second one changes the state to "B". The IP PDUs 
MUST be alternated during the trial. The test SHOULD verify that the 
SUT has properly processed the routing update. 


2.11. Filters 


Filters are added to switches to selectively inhibit the forwarding 

of cells that would normally be forwarded. This is usually done to 

implement security controls on the data that is accepted between one 
area and another. Different products have different capabilities to 
implement filters. Filters are applicable only if the SUT supports 

the filtering feature. 


The SUT SHOULD be first configured to add one filter condition and 
the tests performed. This filter SHOULD permit the forwarding of the 
test data stream. This filter SHOULD be of the form as described in 
the SUT Users Guide. 


The SUT SHOULD be then reconfigured to implement a total of 25 
filters. The first 24 of these filters SHOULD be based on 24 
separate ATM NSAP Network Prefix addresses. 


The 24 ATM NSAP Network Prefix addresses SHOULD not be any that are 
represented in the test data stream. The last filter SHOULD permit 
the forwarding of the test data stream. By "first" and "last" we 
mean to ensure that in the second case, 25 conditions must be checked 
before the data IP over ATM PDUs will match the conditions that 
permit the forwarding of the IP PDU. Of course, if the SUT reorders 
the filters or does not use a linear scan of the filter rules the 
effect of the sequence in which the filters are input is properly 
lost. 
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The exact filters configuration command lines used SHOULD be included 
with the report of the results. 


2.11.1. Filter Addresses 


Two sets of filter addresses are required, one for the single filter 
case and one for the 25 filter case. 


The single filter case should permit traffic from ATM address [Switch 
Network Prefix] 00 00 00 00 00 01 00 to ATM address [Switch Network 
Prefix] 00 00 00 00 00 02 00 and deny all other traffic. Note that 
the 13 octet Switch Network Prefix MUST be configured before this 
test can be run. 


The 25 filter case should follow the following sequence. 


deny [Switch Network Prefix] 00 00 00 00 00 01 00 

to [Switch Network Prefix] 00 00 00 00 00 03 00 
deny [Switch Network Prefix] 00 00 00 00 00 01 00 

to [Switch Network Prefix] 00 00 00 00 00 04 00 
deny [Switch Network Prefix] 00 00 00 00 00 01 00 

to [Switch Network Prefix] 00 00 00 00 00 05 00 


deny [Switch Network Prefix] 00 00 00 00 00 01 00 

to [Switch Network Prefix] 00 00 00 00 00 OC 00 
deny [Switch Network Prefix] 00 00 00 00 00 01 00 

to [Switch Network Prefix] 00 00 00 00 00 OD 00 
allow [Switch Network Prefix] 00 00 00 00 00 01 00 

to [Switch Network Prefix] 00 00 00 00 00 02 00 
deny [Switch Network Prefix] 00 00 00 00 00 01 00 

to [Switch Network Prefix] 00 00 00 00 00 OE 00 
deny [Switch Network Prefix] 00 00 00 00 00 01 00 

to [Switch Network Prefix] 00 00 00 00 00 OF 00 


deny [Switch Network Prefix] 00 00 00 00 00 01 00 
to [Switch Network Prefix] 00 00 00 00 00 18 00 
deny all else 


All previous filter conditions should be cleared from the switch 
before this sequence is entered. The sequence is selected to test to 
see if the switch sorts the filter conditions or accepts them in the 
order that they were entered. Both of these procedures will result 
in a greater impact on performance than will some form of hash 
coding. 


Dunn & Martin Informational [Page 11] 


RFC 3116 Methodology for ATM Benchmarking June 2001 


2.12. Protocol addresses 


It is easier to implement these tests using a single logical stream 
of data, with one source ATM address and one destination ATM address, 
and for some conditions like the filters described above, a practical 
requirement. Networks in the real world are not limited to single 
streams of data. The test suite SHOULD be first run with a single 
ATM source and destination address pair. The tests SHOULD then be 
repeated with using a random destination address. In the case of 
testing single switches, the addresses SHOULD be random and uniformly 
distributed over a range of 256 seven octet user parts. In the case 
of testing multiple interconnected switches, the addresses SHOULD be 
random and uniformly distributed over the 256 network prefixes, each 
of which should support 256 seven octet user parts. The specific 
address ranges to use for ATM are shown in Appendix A. IP to ATM 
address mapping MUST be accomplished as described in RFC 2225. 


2.13. Route Set Up 


It is not reasonable that all of the routing information necessary to 
forward the test stream, especially in the multiple address case, 
will be manually set up. If PNNI and/or ILMI are running, at the 
start of each trial a routing update MUST be sent to the SUT. This 
routing update MUST include all of the ATM addresses that will be 
required for the trial. This routing update will have to be repeated 
at the interval required by PNNI or ILMI. An example of the format 
and repetition interval of the update IP PDUs is given in Appendix B 
(interval and size) and Appendix C (format). 


2.14. Bidirectional traffic 


Bidirectional performance tests SHOULD be run with the same data rate 
being offered from each direction. The sum of the data rates should 
not exceed the theoretical limit for the media. 


2.15. Single stream path 


The full suite of tests SHOULD be run with the appropriate modifiers 
for a single receive and transmit port on the SUT. If the internal 
design of the SUT has multiple distinct pathways, for example, 
multiple interface cards each with multiple network ports, then all 
possible permutations of pathways SHOULD be tested separately. If 
multiple interconnected switches are tested, the test MUST specify 
routes, which allow only one path between source and destination ATM 
addresses. 
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2.16. Multi-port 


Many switch products provide several network ports on the same 
interface module. Each port on an interface module SHOULD be 
stimulated in an identical manner. Specifically, half of the ports 
on each module SHOULD be receive ports and half SHOULD be transmit 
ports. For example if a SUT has two interface module each of which 
has four ports, two ports on each interface module be receive ports 
and two will be transmit ports. Each receive port MUST be offered 
the same data rate. The addresses in the input data streams SHOULD 
be set so that an IP PDU will be directed to each of the transmit 
ports in sequence. That is, all transmit ports will receive an 
identical distribution of IP PDUs from a particular receive port. 


Consider the following 6 port SUT: 


The addressing of the data streams for each of the inputs SHOULD be: 


stream sent to Rx A: 

IP PDU to Tx X, IP PDU to Tx Y, IP PDU to Tx Z 
stream sent to Rx B: 

IP PDU to Tx X, IP PDU to Tx Y, IP PDU to Tx Z 
stream sent to Rx C 

IP PDU to Tx X, IP PDU to Tx Y, IP PDU to Tx Z 


Note: Each stream contains the same sequence of IP destination 
addresses; therefore, each transmit port will receive 3 IP PDUs 
simultaneously. This procedure ensures that the SUT will have to 
process multiple IP PDUs addressed to the same transmit port 
simultaneously. 


The same configuration MAY be used to perform a bi-directional 


multi-stream test. In this case all of the ports are considered both 
receive and transmit ports. Each data stream MUST consist of IP PDUs 
whose addresses correspond to the ATM addresses all of the other 
ports. 
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2.17. Multiple protocols 


This document does not address the issue of testing the effects of a 
mixed protocol environment other than to suggest that if such tests 
are wanted then PDUs SHOULD be distributed between all of the test 
protocols. The distribution MAY approximate the conditions on the 
network in which the SUT would be used. 


2.18. Multiple IP PDU sizes 


This document does not address the issue of testing the effects of a 
mixed IP PDU size environment other than to suggest that, if such 
tests are required, then IP PDU size SHOULD be evenly distributed 


among all of the PDU sizes listed in this document. The distribution 
MAY approximate the conditions on the network in which the SUT would 
be used. 


2.19. Testing beyond a single SUT 


In the performance testing of a single SUT, the paradigm can be 
described as applying some input to a SUT and monitoring the output. 
The results of which can be used to form a basis of characterization 
of that device under those test conditions. 


This model is useful when the test input and output are homogeneous 
(e.g., 64-byte IP, AAL5 PDUs into the SUT; 64 byte IP, AAL5 PDUs 
out). 


By extending the single SUT test model, reasonable benchmarks 
regarding multiple SUTs or heterogeneous environments may be 
collected. In this extension, the single SUT is replaced by a system 
of interconnected network SUTs. This test methodology would support 
the benchmarking of a variety of device/media/service/protocol 
combinations. For example, a configuration for a LAN-to-WAN-to-LAN 
test might be: 


(1) ATM UNI -> SUT 1 -> BISUP -> SUT 2 -> ATM UNI 


Or an extended LAN configuration might be: 
(2) ATM UNI -> SUT 1 -> PNNI Network -> SUT 2 -> ATM UNI 


In both examples 1 and 2, end-to-end benchmarks of each system could 
be empirically ascertained. Other behavior may be characterized 
through the use of intermediate devices. In example 2, the 
configuration may be used to give an indication of the effect of PNNI 
routing on IP throughput. 
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Because multiple SUTs are treated as a single system, there are 
limitations to this methodology. For instance, this methodology may 
yield an aggregate benchmark for a tested system. That benchmark 
alone, however, may not necessarily reflect asymmetries in behavior 
between the SUTs, latencies introduced by other apparatus (e.g., 
CSUs/DSUs, switches), etc. 


Further, care must be used when comparing benchmarks of different 
systems by ensuring that the SUTs’ features and configuration of the 
tested systems have the appropriate common denominators to allow 
comparison. 


2.20. Maximum IP PDU rate 


The maximum IP PDU rates that should be used when testing LAN 
connections SHOULD be the listed theoretical maximum rate for the IP 
PDU size on the media. 


The maximum IP PDU rate that should be used when testing WAN 
connections SHOULD be greater than the listed theoretical maximum 
rate for the IP PDU size on that speed connection. The higher rate 
for WAN tests is to compensate for the fact that some vendors employ 
various forms of header compression. 


A list of maximum IP PDU rates for LAN connections is included in 
Appendix B. 


2.21. Bursty traffic 


It is convenient to measure the SUT performance under steady state 
load; however, this is an unrealistic way to gauge the functioning of 
a SUT. Actual network traffic normally consists of bursts of IP 
PDUs. 


Some of the tests described below SHOULD be performed with both 
constant bit rate, bursty Unspecified Bit Rate (UBR) Best Effort 
[AF-TM4.1] and Variable Bit Rate Non-real Time (VBR-nrt) Best Effort 
[AF-TM4.1]. The IP PDUs within a burst are transmitted with the 
minimum legitimate inter-IP PDU gap. 


The objective of the test is to determine the minimum interval 
between bursts that the SUT can process with no IP PDU loss. Tests 
SHOULD be run with burst sizes of 10% of Maximum Burst Size (MBS), 
20% of MBS, 50% of MBS and 100% MBS. Note that the number of IP PDUs 
in each burst will depend on the PDU size. For UBR, the MBS refers 
to the associated VBR traffic parameters. 
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2.22. Trial description 
A particular test consists of multiple trials. Each trial returns 
one piece of information, for example the loss rate at a particular 


input IP PDU rate. Each trial consists of five of phases: 


a) If the SUT is a switch supporting PNNI, send the routing update to 
the SUT receive port and wait two seconds to be sure that the 
routing has settled. 


b) Send an ATM ARP PDU to determine the ATM address corresponding to 
the destination IP address. The formats of the ATM ARP PDU that 
should be used are shown in the Test Frame Formats document and 
MUST be in accordance with RFC 2225. 

c) Stimulate SUT with traffic load. 

d) Wait for two seconds for any residual IP PDUs to be received. 


e) Wait for at least five seconds for the SUT to restabilize. 


2.23. Trial duration 


The objective of the tests defined in this document is to accurately 
characterize the behavior of a particular piece of network equipment 
under varying traffic loads. The choice of test duration must be a 
compromise between this objective and keeping the duration of the 
benchmarking test suite within reasonable bounds. The SUT SHOULD be 
stimulated for at least 60 seconds. If this time period results ina 
high variance in the test results, the SUT SHOULD be stimulated for 
at least 300 seconds. 


2.24. Address resolution 


The SUT MUST be able to respond to address resolution requests sent 
by another SUT, an ATM ARP server or the test equipment in accordance 
with RFC 2225. 


2.25. Synchronized Payload Bit Pattern. 


Some measurements assume that both the transmitter and receiver 
payload information is synchronized. Synchronization MUST be 
achieved by supplying a known bit pattern to both the transmitter and 
receiver. This bit pattern MUST be one of the following: PRBS-15, 
PRBS-23, OxFFOO, or OxAA55. 
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2.26. Burst Traffic Descriptors. 


Some measurements require busty traffic patterns. These patterns 
MUST conform to one of the following traffic descriptors: 


1) PCR=100% allotted line rate, SCR=50% allotted line rate, and MBS=8192 
2) PCR=100% allotted line rate, SCR=50% allotted line rate, and MBS=4096 
3) PCR=90% allotted line rate, SCR=50% allotted line rate, and MBS=8192 
4) PCR=90% allotted line rate, SCR=50% allotted line rate, and MBS=4096 
5) PCR=90% allotted line rate, SCR=45% allotted line rate, and MBS=8192 


6) PCR=90% allotted line rate, SCR=45% allotted line rate, and MBS=4096 


7) PCR=80% allotted line rate, SCR=40% allotted line rate, and MBS=65536 


8) PCR=80% allotted line rate, SCR=40% allotted line rate, and MBS=32768 


The allotted line rate refers to the total available line rate 
divided by the number of VCCs in use. 


3. Performance Metrics 

3.1. Physical Layer-SONET 

3.1.1. Pointer Movements 

3.1.1.1. Pointer Movement Propagation. 


Objective: To determine that the SUT does not propagate pointer 
movements as defined in RFC 2761 "Terminology for ATM Benchmarking". 


Procedure: 

1) Set up the SUT and test device using the uni-directional 
configuration. 

2) Send a specific number of IP PDUs at a specific rate through the 


SUT. Since this test is not a throughput test, the rate should 
not be greater than 90% of line rate. The cell payload SHOULD 
contain valid IP PDUs. The IP PDUs MUST be encapsulated in AAL5. 
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3) 


11) 


12) 


13) 


Count the IP PDUs that are transmitted by the SUT to verify 
connectivity and load. If the count on the test device is the 
same on the SUT, continue the test, else lower the test device 
traffic rate until the counts are the same. 


Inject one forward payload pointer movement. Verify that the SUT 
does not change the pointer. 


Inject one forward payload pointer movement every 1 second. 
Verify that the SUT does not change the pointer. 


Discontinue the payload pointer movement. 


Inject five forward payload pointer movements every 1 second. 
Verify that the SUT does not change the pointer. 


Discontinue the payload pointer movement. 


Inject one backward payload pointer movement. Verify that the 
SUT does not change the pointer. 


Inject one backward payload pointer movement every 1 second. 
Verify that the SUT does not change the pointer. 


Discontinue the payload pointer movement. 


Inject five backward payload pointer movements every 1 second. 
Verify that the SUT does not change the pointer. 


Discontinue the payload pointer movement. 


Reporting Format: 


The results of the pointer movement propagation test SHOULD be 
reported in a form of a table. The rows SHOULD be labeled single 
pointer movement, one pointer movement per second, and five 
pointer movements per second. The columns SHOULD be labeled 
pointer movement and loss of pointer. The elements of the table 
SHOULD be either True or False, indicating whether the particular 
condition was observed for each test. 


The table MUST also indicate the IP PDU size in octets and traffic 
rate in IP PDUs per second as generated by the test device. 
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3.1.1.2. Cell Loss due to Pointer Movement. 


Objective: To determine if the SUT will drop cells due to pointer 
movements as defined in RFC 2761 "Terminology for ATM Benchmarking". 


Procedure: 


1) 


11) 


12) 


13) 


Dunn & 


Set up the SUT and test device using the uni-directional 
configuration. 


Send a specific number of cells at a specific rate through the 
SUT. Since this test is not a throughput test, the rate should 
not be greater than 90% of line rate. The cell payload SHOULD 
contain valid IP PDUs. The IP PDUs MUST be encapsulated in AAL5. 
Count the cells that are transmitted by the SUT to verify 
connectivity and load. If the count on the test device is the 
same on the SUT, continue the test; else lower the test device 
traffic rate until the counts are the same. 


Inject one forward payload pointer movement. Verify that the SUT 
does not drop any cells. 


Inject one forward payload pointer movement every 1 second. 
Verify that the SUT does not drop any cells. 


Discontinue the payload pointer movement. 


Inject five forward payload pointer movements every 1 second. 
Verify that the SUT does not drop any cells. 


Discontinue the payload pointer movement. 


Inject one backward payload pointer movement. Verify that the 
SUT does not drop any cells. 


Inject one backward payload pointer movement every 1 second. 
Verify that the SUT does not drop any cells. 


Discontinue the payload pointer movement. 


Inject five backward payload pointer movements every 1 second. 
Verify that the SUT does not drop any cells. 


Discontinue the payload pointer movement. 
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Reporting Format: 


The results of the cell loss due to pointer movement test SHOULD 
be reported in a form of a table. The rows SHOULD be labeled 
single pointer movement, one pointer movement per second, and five 
pointer movements per second. The columns SHOULD be labeled cell 
loss and number of cells lost. The elements of column 1 SHOULD be 
either True or False, indicating whether the particular condition 
was observed for each test. The elements of column 2 SHOULD be 
non-negative integers. 


The table MUST also indicate the traffic rate in IP PDUs per 
second as generated by the test device. 


3.1.1.3. IP Packet Loss due to Pointer Movement. 


Objective: To determine if the SUT will drop IP packets due to 
pointer movements as defined in RFC 2761 "Terminology for ATM 
Benchmarking". 


Procedure: 


1) 


Set up the SUT and test device using the uni-directional 
configuration. 


Send a specific number of IP packets at a specific rate through 
the SUT. Since this test is not a throughput test, the rate 
should not be greater than 90% of line rate. The IP PDUs MUST be 
encapsulated in AAL5. 


Count the IP packets that are transmitted by the SUT to verify 
connectivity and load. If the count on the test device is the 
same on the SUT, continue the test; else lower the test device 
traffic rate until the counts are the same. 


Inject one forward payload pointer movement. Verify that the SUT 
does not drop any packets. 


Inject one forward payload pointer movement every 1 second. 
Verify that the SUT does not drop any packets. 


Discontinue the payload pointer movement. 


Inject five forward payload pointer movements every 1 second. 
Verify that the SUT does not drop any packets. 


Discontinue the payload pointer movement. 
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9) 


10) 


11) 


12) 


13) 


Inject one backward payload pointer movement. Verify that the 
SUT does not drop any packets. 


Inject one backward payload pointer movement every 1 second. 
Verify that the SUT does not drop any packets. 


Discontinue the payload pointer movement. 


Inject five backward payload pointer movements every 1 second. 
Verify that the SUT does not drop any packets. 


Discontinue the payload pointer movement. 


Reporting Format: 


Sl ne aes 


The results of the IP packet loss due to pointer movement test 
SHOULD be reported in a form of a table. The rows SHOULD be 
labeled single pointer movement, one pointer movement per second, 
and five pointer movements per second. The columns SHOULD be 


labeled packet loss and number of packets lost. The elements of 
column 1 SHOULD be either True or False, indicating whether the 
particular condition was observed for each test. The elements of 


column 2 SHOULD be non-negative integers. 


The table MUST also indicate the packet size in octets and traffic 
rate in packets per second as generated by the test device. 


Transport Overhead (TOH) Error Count 


3.1.2.1. TOH Error Propagation. 


Objective: To determine that the SUT does not propagate TOH errors as 
defined in RFC 2761 "Terminology for ATM Benchmarking". 


Procedure: 


1) 


Set up the SUT and test device using the uni-directional 
configuration. 


Send a specific number of IP PDUs at a specific rate through the 
SUT. Since this test is not a throughput test, the rate should 
not be greater than 90% of line rate. The cell payload SHOULD 
contain valid IP PDUs. The IP PDUs MUST be encapsulated in AAL5. 


Count the IP PDUs that are transmitted by the SUT to verify 
connectivity and load. If the count on the test device is the 
same on the SUT, continue the test, else lower the test device 
traffic rate until the counts are the same. 
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8) 


Inject one error in the first bit of the Al and A2 Frameword. 
Verify that the SUT does not propagate the error. 


Inject one error in the first bit of the Al and A2 Frameword 
every 1 second. Verify that the SUT does not propagate the 


error. 


Discontinue the Frameword error. 


Inject one error in the first bit of the Al and A2 Frameword for 
4 consecutive IP PDUs in every 6 IP PDUs. Verify that the SUT 
indicates Loss of Frame. 


Discontinue the Frameword error. 


Reporting Format: 


The results of the TOH error propagation test SHOULD be reported 
in a form of a table. The rows SHOULD be labeled single error, 
one error per second, and four consecutive errors every 6 IP PDUs. 
The columns SHOULD be labeled error propagated and loss of IP PDU. 
The elements of the table SHOULD be either True or False, 
indicating whether the particular condition was observed for each 
test. 


The table MUST also indicate the IP PDU size in octets and traffic 
rate in IP PDUs per second as generated by the test device. 


3.1.2.2. c TOH Error. 


Objective: To determine if the SUT will drop cells due TOH Errors as 
defined in RFC 2761 "Terminology for ATM Benchmarking". 


Procedure: 


1) 


Set up the SUT and test device using the uni-directional 
configuration. 


Send a specific number of cells at a specific rate through the 
SUT. Since this test is not a throughput test, the rate should 
not be greater than 90% of line rate. The cell payload SHOULD 
contain valid IP PDUs. The IP PDUs MUST be encapsulated in AAL5. 


Count the cells that are transmitted by the SUT to verify 
connectivity and load. If the count on the test device is the 
same on the SUT, continue the test; else lower the test device 
traffic rate until the counts are the same. 
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8) 


Inject one error in the first bit of the Al and A2 Frameword. 
Verify that the SUT does not drop any cells. 


Inject one error in the first bit of the Al and A2 Frameword 
every 1 second. Verify that the SUT does not drop any cells. 


Discontinue the Frameword error. 
Inject one error in the first bit of the Al and A2 Frameword for 
4 consecutive IP PDUs in every 6 IP PDUs. Verify that the SUT 


does drop cells. 


Discontinue the Frameword error. 


Reporting Format: 


The results of the Cell Loss due to TOH errors test SHOULD be 
reported in a form of a table. The rows SHOULD be labeled single 
error, one error per second, and four consecutive errors every 6 
IP PDUs. The columns SHOULD be labeled cell loss and number of 
cells lost. The elements of column 1 SHOULD be either True or 
False, indicating whether the particular condition was observed 
for each test. The elements of column 2 SHOULD be non-negative 
integers. 


The table MUST also indicate the traffic rate in IP PDUs per 
second as generated by the test device. 


3.1.2.3. IP Packet Loss due to TOH Error. 


Objective: To determine if the SUT will drop IP packets due to TOH 
errors as defined in RFC 2761 "Terminology for ATM Benchmarking". 


Procedure: 


1) 


Set up the SUT and test device using the uni-directional 
configuration. 


Send a specific number of IP packets at a specific rate through 
the SUT. Since this test is not a throughput test, the rate 
should not be greater than 90% of line rate. The IP PDUs MUST be 
encapsulated in AAL5. 


Count the IP packets that are transmitted by the SUT to verify 
connectivity and load. If the count on the test device is the 
same on the SUT, continue the test; else lower the test device 
traffic rate until the counts are the same. 
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8) 


Inject one error in the first bit of the Al and A2 Frameword. 
Verify that the SUT does not drop any packets. 


Inject one error in the first bit of the Al and A2 Frameword 
every 1 second. Verify that the SUT does not drop any packets. 


Discontinue the Frameword error. 
Inject one error in the first bit of the Al and A2 Frameword for 
4 consecutive IP PDUs in every 6 IP PDUs. Verify that the SUT 


does drop packets. 


Discontinue the Frameword error. 


Reporting Format: 


32.143: 


3.1.53 


The results of the IP packet loss due to TOH errors test SHOULD be 
reported in a form of a table. The rows SHOULD be labeled single 
error, one error per second, and four consecutive errors every 6 

IP PDUs. The columns SHOULD be labeled packet loss and number of 


packets lost. The elements of column 1 SHOULD be either True or 
False, indicating whether the particular condition was observed 
for each test. The elements of column 2 SHOULD be non-negative 
integers. 


The table MUST also indicate the packet size in octets and traffic 
rate in packets per second as generated by the test device. 


Path Overhead (POH) Error Count 


.1. POH Error Propagation. 


Objective: To determine that the SUT does not propagate POH errors as 
defined in RFC 2761 "Terminology for ATM Benchmarking". 


Procedure: 


1) 


Set up the SUT and test device using the uni-directional 
configuration. 


Send a specific number of IP PDUs at a specific rate through the 
SUT. Since this test is not a throughput test, the rate should 
not be greater than 90% of line rate. The cell payload SHOULD 
contain valid IP PDUs. The IP PDUs MUST be encapsulated in AAL5. 
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3) 


6) 


Count the IP PDUs that are transmitted by the SUT to verify 
connectivity and load. If the count on the test device is the 
same on the SUT, continue the test, else lower the test device 
traffic rate until the counts are the same. 


Inject one error in the B3 (Path BIP8) byte. Verify that the SUT 
does not propagate the error. 


Inject one error in the B3 byte every 1 second. Verify that the 
SUT does not propagate the error. 


Discontinue the POH error. 


Reporting Format: 


The results of the POH error propagation test SHOULD be reported 
in a form of a table. The rows SHOULD be labeled single error 
and one error per second. The columns SHOULD be labeled error 
propagated and loss of IP PDU. The elements of the table SHOULD 
be either True or False, indicating whether the particular 
condition was observed for each test. 


The table MUST also indicate the IP PDU size in octets and 
traffic rate in IP PDUs per second as generated by the test 
device. 


3.1.3.2. Cell Loss due to POH Error. 


Objective: To determine if the SUT will drop cells due POH Errors as 
defined in RFC 2761 "Terminology for ATM Benchmarking". 


Procedure: 


1) 


Dunn & 


Set up the SUT and test device using the uni-directional 
configuration. 


Send a specific number of cells at a specific rate through the 
SUT. Since this test is not a throughput test, the rate should 
not be greater than 90% of line rate. The cell payload SHOULD 
contain valid IP PDUs. The IP PDUs MUST be encapsulated in AAL5. 


Count the cells that are transmitted by the SUT to verify 
connectivity and load. If the count on the test device is the 
same on the SUT, continue the test; else lower the test device 
traffic rate until the counts are the same. 


Inject one error in the B3 (Path BIP8) byte. Verify that the SUT 
does not drop any cells. 


Martin Informational [Page 25] 


RFC 3116 Methodology for ATM Benchmarking June 2001 


5) 


6) 


Inject one error in the B3 byte every 1 second. Verify that the 
SUT does not drop any cells. 


Discontinue the POH error. 


Reporting Format: 


The results of the Cell Loss due to POH errors test SHOULD be 
reported in a form of a table. The rows SHOULD be labeled single 
error and one error per second. The columns SHOULD be labeled 
cell loss and number of cells lost. The elements of column 1 
SHOULD be either True or False, indicating whether the particular 
condition was observed for each test. The elements of column 2 
SHOULD be non-negative integers. 


The table MUST also indicate the traffic rate in IP PDUs per 
second as generated by the test device. 


3.1.3.3. IP Packet Loss due to POH Error. 


Objective: To determine if the SUT will drop IP packets due to POH 
errors as defined in RFC 2761 "Terminology for ATM Benchmarking". 


Procedure: 


1) 


Set up the SUT and test device using the uni-directional 
configuration. 


Send a specific number of IP packets at a specific rate through 
the SUT. Since this test is not a throughput test, the rate 
should not be greater than 90% of line rate. The IP PDUs MUST be 
encapsulated in AAL5. 


Count the IP packets that are transmitted by the SUT to verify 
connectivity and load. If the count on the test device is the 
same on the SUT, continue the test; else lower the test device 
traffic rate until the counts are the same. 


Inject one error in the B3 (Path BIP8) byte. Verify that the SUT 
does not drop any packets. 


Inject one error in the B3 byte every 1 second. Verify that the 
SUT does not drop any packets. 


Discontinue the POH error. 


Dunn & Martin Informational [Page 26] 


RFC 3116 Methodology for ATM Benchmarking June 2001 


Reporting Format: 


The results of the IP packet loss due to POH errors test SHOULD be 
reported in a form of a table. The rows SHOULD be labeled single 
error and one error per second. The columns SHOULD be labeled 
packet loss and number of packets lost. The elements of column 1 
SHOULD be either True or False, indicating whether the particular 
condition was observed for each test. The elements of column 2 
SHOULD be non-negative integers. 


The table MUST also indicate the packet size in octets and traffic 
rate in packets per second as generated by the test device. 


3.2. ATM Layer 
3.2.1. Two-Point Cell Delay Variation (CDV) 
3.2.1.1. Test Setup 


The cell delay measurements assume that both the transmitter and 
receiver timestamp information is synchronized. Synchronization 
SHOULD be achieved by supplying a common clock signal (minimum of 100 
Mhz or 10 ns resolution) to both the transmitter and receiver. The 
maximum timestamp values MUST be recorded to ensure synchronization 
in the case of counter rollover. The cell delay measurements SHOULD 
utilize the 0.191 cell (ITUT-0.191) encapsulated in a valid IP 
packet. If the 0.191 cell is not available, a test cell encapsulated 
in a valid IP packet MAY be used. The test cell MUST contain a 
transmit timestamp which can be correlated with a receive timestamp. 
A description of the test cell MUST be included in the test results. 
The description MUST include the timestamp length (in bits), counter 
rollover value, and the timestamp accuracy (in ns). 


3.2.1.2. Two-point CDV/Steady Load/One VCC 


Objective: To determine the SUT variation in cell transfer delay with 
one VCC as defined in RFC 2761 "Terminology for ATM Benchmarking". 


Procedure: 


1) Set up the SUT and test device using the bi-directional 
configuration. 


2) Configure the SUT and test device with one VCC. The VCC SHOULD 
contain one VPI/VCI. The VCC MUST be configured as either a CBR, 
VBR, or UBR connection. The VPI/VCI MUST not be one of the 
reserved ATM signaling channels (e.g., [0,5], [0,16]). 
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3) 


5) 


Send a specific number of IP packets containing timestamps at a 

specific constant rate through the SUT via the defined test VCC. 
Since this test is not a throughput test, the rate should not be 
greater than 90% of line rate. The IP PDUs MUST be encapsulated 
in AALS. 


Count the IP packets that are transmitted by the SUT to verify 
connectivity and load. If the count on the test device is the 
same on the SUT, continue the test; else lower the test device 
traffic rate until the counts are the same. 


Record the packets timestamps at the transmitter and receiver 
ends of the test device. 


Reporting Format: 


The results of the Two-point CDV/Steady Load/One VCC test SHOULD 
be reported in a form of text, graph, and histogram. 


The text results SHOULD display the numerical values of the CDV. 
The values given SHOULD include: time period of test in s, test 
VPI/VCI value, total number of cells transmitted and received on 
the given VPI/VCI during the test in positive integers, maximum 
and minimum CDV during the test in us, and peak-to-peak CDV in us. 


The graph results SHOULD display the cell delay values. The x- 
coordinate SHOULD be the test run time in either seconds, minutes 
or days depending on the total length of the test. The x- 
coordinate time SHOULD be configurable. The y-coordinate SHOULD 
be the cell delay in us. The integration time per point MUST be 
indicated. 


The histogram results SHOULD display the peak-to-peak cell delay. 
The x-coordinate SHOULD be the cell delay in us with at least 256 
bins. The y-coordinate SHOULD be the number of cells observed in 
each bin. 


The results MUST also indicate the packet size in octets, traffic 
rate in packets per second, and bearer class as generated by the 
test device. The VCC and VPI/VCI values MUST be indicated. The 
bearer class of the created VCC MUST also be indicated. 


3.2.1.3. Two-point CDV/Steady Load/Twelve VCCs 


Objective: To determine the SUT variation in cell transfer delay with 
twelve VCCs as defined in RFC 2761 "Terminology for ATM 
Benchmarking". 
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Procedure: 


1) 


5) 


Set up the SUT and test device using the bi-directional 
configuration. 


Configure the SUT and test device with twelve VCCs, using 1 VPI 

and 12 VCIs. The VCC’s MUST be configured as either a CBR, VBR, 
or UBR connection. The VPI/VCIs MUST not be one of the reserved 
ATM signaling channels (e.g., [0,5], [0,16]). 


Send a specific number of IP packets containing timestamps at a 
specific constant rate through the SUT via the defined test VCCs. 
All of the VPI/VCI pairs will generate traffic at the same 
traffic rate. Since this test is not a throughput test, the rate 
should not be greater than 90% of line rate. The IP PDUs MUST be 
encapsulated in AAL5. 


Count the IP packets that are transmitted by the SUT on all VCCs 
to verify connectivity and load. If the count on the test device 
is the same on the SUT, continue the test; else lower the test 
device traffic rate until the counts are the same. 


Record the packets timestamps at the transmitter and receiver 
ends of the test device for all VCCs. 


Reporting Format: 


The results of the Two-point CDV/Steady Load/Twelve VCCs test 
SHOULD be reported in a form of text, graph, and histograms. 


The text results SHOULD display the numerical values of the CDV. 
The values given SHOULD include: time period of test in s, test 
VPI/VCI values, total number of cells transmitted and received on 
each VCC during the test in positive integers, maximum and minimum 
CDV on each VCC during the test in us, and peak-to-peak CDV on 
each VCC in us. 


The graph results SHOULD display the cell delay values. The x- 
coordinate SHOULD be the test run time in either seconds, minutes 
or days depending on the total length of the test. The x- 
coordinate time SHOULD be configurable. The y-coordinate SHOULD 
be the cell delay for each VCC in ms. There SHOULD be 12 curves 
on the graph, one curves indicated and labeled for each VCC. The 
integration time per point MUST be indicated. 
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The histograms SHOULD display the peak-to-peak cell delay. There 
will be one histogram for each VCC. The x-coordinate SHOULD be 
the cell delay in us with at least 256 bins. The y-coordinate 
SHOULD be the number of cells observed in each bin. 


The results MUST also indicate the packet size in octets, traffic 
rate in packets per second, and bearer class as generated by the 
test device. The VCC and VPI/VCI values MUST be indicated. The 
bearer class of the created VCC MUST also be indicated. 


3.2.1.4. Two-point CDV/Steady Load/Maximum VCCs 


Objective: To determine the SUT variation in cell transfer delay with 
the maximum number VCCs supported on the SUT as defined in RFC 2761 
"Terminology for ATM Benchmarking". 


Procedure: 


1) 


5) 


Set up the SUT and test device using the bi-directional 
configuration. 


Configure the SUT and test device with the maximum number of VCCs 
supported on the SUT. For example, if the maximum number of VCCs 
supported on the SUT is 1024, define 256 VPIs with 4 VCIs per 
VPI. The VCC’s MUST be configured as either a CBR, VBR, or UBR 
connection. The VPI/VCIs MUST not be one of the reserved ATM 
signaling channels (e.g., [0,5], [0,16]). 


Send a specific number of IP packets containing timestamps at a 
specific constant rate through the SUT via the defined test VCCs. 
All of the VPI/VCI pairs will generate traffic at the same 
traffic rate. Since this test is not a throughput test, the rate 
should not be greater than 90% of line rate. The IP PDUs MUST be 
encapsulated in AAL5. 


Count the IP packets that are transmitted by the SUT on all VCCs 
to verify connectivity and load. If the count on the test device 
is the same on the SUT, continue the test; else lower the test 
device traffic rate until the counts are the same. 


Record the packets timestamps at the transmitter and receiver 
ends of the test device for all VCCs. 


Reporting Format: 


The results of the Two-point CDV/Steady Load/Maximum VCCs test 
SHOULD be reported in a form of text, graphs, and histograms. 
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The text results SHOULD display the numerical values of the CDV. 
The values given SHOULD include: time period of test in s, test 
VPI/VCI values, total number of cells transmitted and received on 
each VCC during the test in positive integers, maximum and minimum 
CDV on each VCC during the test in us, and peak-to-peak CDV on 
each VCC in us. 


The graph results SHOULD display the cell delay values. There 
will be (Max number of VCCs/10) graphs, with 10 VCCs indicated on 
each graph. The x-coordinate SHOULD be the test run time in 
either seconds, minutes or days depending on the total length of 
the test. The x-coordinate time SHOULD be configurable. The y- 
coordinate SHOULD be the cell delay for each VCC in us. There 
SHOULD be no more than 10 curves on each graph, one curve 
indicated and labeled for each VCC. The integration time per 
point MUST be indicated. 


The histograms SHOULD display the peak-to-peak cell delay. There 
will be one histogram for each VCC. The x-coordinate SHOULD be 
the cell delay in us with at least 256 bins. The y-coordinate 
SHOULD be the number of cells observed in each bin. 


The results MUST also indicate the packet size in octets, traffic 
rate in packets per second, and bearer class as generated by the 
test device. The VCC and VPI/VCI values MUST be indicated. The 
bearer class of the created VCC MUST also be indicated. 


3.2.1.5. Two-point CDV/Bursty VBR Load/One VCC 


Objective: To determine the SUT variation in cell transfer delay with 
one VCC as defined in RFC 2761 "Terminology for ATM Benchmarking". 


Procedure: 


1) 


Set up the SUT and test device using the bi-directional 
configuration. 


Configure the SUT and test device with one VCC. The VCC SHOULD 

contain one VPI/VCI. The VCC MUST be configured as either a CBR 
or VBR connection. The VPI/VCI MUST not be one of the reserved 

ATM signaling channels (e.g., [0,5], [0,16]). 


Send a specific number of IP packets containing timestamps at a 
specific VBR through the SUT via the defined test VCC. Since 
this test is not a throughput test, the rate should not be 
greater than 90% of line rate. The IP PDUs MUST be encapsulated 
in AALS. 
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4) 


5) 


Count the IP packets that are transmitted by the SUT to verify 
connectivity and load. If the count on the test device is the 
same on the SUT, continue the test; else lower the test device 
traffic rate until the counts are the same. 


Record the packets timestamps at the transmitter and receiver 
ends of the test device. 


Reporting Format: 


The results of the Two-point CDV/Bursty VBR Load/One VCC test 
SHOULD be reported in a form of text, graph, and histogram. 


The text results SHOULD display the numerical values of the CDV. 
The values given SHOULD include: time period of test in s, test 
VPI/VCI value, total number of cells transmitted and received on 
the given VPI/VCI during the test in positive integers, maximum 
and minimum CDV during the test in us, and peak-to-peak CDV in us. 


The graph results SHOULD display the cell delay values. The x- 
coordinate SHOULD be the test run time in either seconds, minutes 
or days depending on the total length of the test. The x- 
coordinate time SHOULD be configurable. The y-coordinate SHOULD 
be the cell delay in us. The integration time per point MUST be 
indicated. 


The histogram results SHOULD display the peak-to-peak cell delay. 
The x-coordinate SHOULD be the cell delay in us with at least 256 
bins. The y-coordinate SHOULD be the number of cells observed in 
each bin. 


The results MUST also indicate the packet size in octets, traffic 
rate in packets per second, and bearer class as generated by the 
test device. The VCC and VPI/VCI values MUST be indicated. The 
PCR, SCR, and MBS MUST be indicated. The bearer class of the 
created VCC MUST also be indicated. 


3.2.1.6. Two-point CDV/Bursty VBR Load/Twelve VCCs 


Objective: To determine the SUT variation in cell transfer delay with 
twelve VCCs as defined in RFC 2761 "Terminology for ATM 
Benchmarking". 


Procedure: 


1) 


Set up the SUT and test device using the bi-directional 
configuration. 
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2) 


5) 


Configure the SUT and test device with twelve VCCs, using 1 VPI 
and 12 VCIs. The VCC’s MUST be configured as either a CBR or VBR 
connection. The VPI/VCIs MUST not be one of the reserved ATM 
signaling channels (e.g., [0,5], [0,16]). 


Send a specific number of IP packets containing timestamps at a 
specific VBR through the SUT via the defined test VCCs. All of 
the VPI/VCI pairs will generate traffic at the same traffic rate. 
Since this test is not a throughput test, the rate should not be 
greater than 90% of line rate. The IP PDUs MUST be encapsulated 
in AALS. 


Count the IP packets that are transmitted by the SUT on all VCCs 
to verify connectivity and load. If the count on the test device 
is the same on the SUT, continue the test; else lower the test 
device traffic rate until the counts are the same. 


Record the packets timestamps at the transmitter and receiver 
ends of the test device for all VCCs. 


Reporting Format: 


The results of the Two-point CDV/Bursty VBR Load/Twelve VCCs test 
SHOULD be reported in a form of text, graph, and histograms. 


The text results SHOULD display the numerical values of the CDV. 
The values given SHOULD include: time period of test in s, test 
VPI/VCI values, total number of cells transmitted and received on 
each VCC during the test in positive integers, maximum and minimum 
CDV on each VCC during the test in us, and peak-to-peak CDV on 
each VCC in us. 


The graph results SHOULD display the cell delay values. The x- 
coordinate SHOULD be the test run time in either seconds, minutes 
or days depending on the total length of the test. The x- 
coordinate time SHOULD be configurable. The y-coordinate SHOULD 
be the cell delay for each VCC in ms. There SHOULD be 12 curves 
on the graph, one curves indicated and labeled for each VCC. The 
integration time per point MUST be indicated. 


The histograms SHOULD display the peak-to-peak cell delay. There 
will be one histogram for each VCC. The x-coordinate SHOULD be 
the cell delay in us with at least 256 bins. The y-coordinate 
SHOULD be the number of cells observed in each bin. 
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The results MUST also indicate the packet size in octets, traffic 
rate in packets per second, and bearer class as generated by the 
test device. The VCC and VPI/VCI values MUST be indicated. The 
PCR, SCR, and MBS MUST be indicated. The bearer class of the 
created VCC MUST also be indicated. 


3.2.1.7. Two-point CDV/Bursty VBR Load/Maximum VCCs 


Objective: To determine the SUT variation in cell transfer delay with 
the maximum number VCCs supported on the SUT as defined in RFC 2761 
"Terminology for ATM Benchmarking". 


Procedure: 


1) 


5) 


Set up the SUT and test device using the bi-directional 
configuration. 


Configure the SUT and test device with the maximum number of VCCs 
supported on the SUT. For example, if the maximum number of VCCs 
supported on the SUT is 1024, define 256 VPIs with 4 VCIs per 
VPI. The VCC’s MUST be configured as either a CBR or VBR 
connection. The VPI/VCIs MUST not be one of the reserved ATM 
signaling channels (e.g., [0,5], [0,16]). 


Send a specific number of IP packets containing timestamps at a 
specific VBR through the SUT via the defined test VCCs. All of 
the VPI/VCI pairs will generate traffic at the same traffic rate. 
Since this test is not a throughput test, the rate should not be 
greater than 90% of line rate. The IP PDUs MUST be encapsulated 
in AALS. 


Count the IP packets that are transmitted by the SUT on all VCCs 
to verify connectivity and load. If the count on the test device 
is the same on the SUT, continue the test; else lower the test 
device traffic rate until the counts are the same. 


Record the packets timestamps at the transmitter and receiver 
ends of the test device for all VCCs. 


Reporting Format: 


The results of the Two-point CDV/Bursty VBR Load/Maximum VCCs test 
SHOULD be reported in a form of text, graphs, and histograms. 


The text results SHOULD display the numerical values of the CDV. 
The values given SHOULD include: time period of test in s, test 
VPI/VCI values, total number of cells transmitted and received on 
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each VCC during the test in positive integers, maximum and minimum 
CDV on each VCC during the test in us, and peak-to-peak CDV on 
each VCC in us. 


The graph results SHOULD display the cell delay values. There 
will be (Max number of VCCs/10) graphs, with 10 VCCs indicated on 
each graph. The x-coordinate SHOULD be the test run time in 
either seconds, minutes or days depending on the total length of 
the test. The x-coordinate time SHOULD be configurable. The y- 
coordinate SHOULD be the cell delay for each VCC in us. There 
SHOULD be no more than 10 curves on each graph, one curve 
indicated and labeled for each VCC. The integration time per 
point MUST be indicated. 


The histograms SHOULD display the peak-to-peak cell delay. There 
will be one histogram for each VCC. The x-coordinate SHOULD be 
the cell delay in us with at least 256 bins. The y-coordinate 
SHOULD be the number of cells observed in each bin. 


The results MUST also indicate the packet size in octets, traffic 
rate in packets per second, and bearer class as generated by the 
test device. The VCC and VPI/VCI values MUST be indicated. The 
PCR, SCR, and MBS MUST be indicated. The bearer class of the 
created VCC MUST also be indicated. 


3.2.1.8. Two-point CDV/Mixed Load/Three VCC’s 


Objective: To determine the SUT variation in cell transfer delay with 
three VCC’s as defined in RFC 2761 "Terminology for ATM 
Benchmarking". 


Procedure: 


1) 


Set up the SUT and test device using the bi-directional 
configuration. 


Configure the SUT and test device with three VCC’s. Each VCC 
MUST be defined as a different Bearer class: one CBR, one UBR and 
one VBR. Each VCC SHOULD contain one VPI/VCI. The VPI/VCI MUST 
not be one of the reserved ATM signaling channels (e.g., [0,5], 
[0,16]). 


Send a specific number of IP packets containing timestamps 
through the SUT via the defined test VCCs. Each generated VCC 
stream MUST match the corresponding VCC Bearer class. All of the 
VPI/VCI pairs will generate traffic at the same traffic rate. 
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5) 


Since this test is not a throughput test, the rate should not be 
greater than 90% of line rate. The IP PDUs MUST be encapsulated 
in AAL5. 


Count the IP packets that are transmitted by the SUT to verify 
connectivity and load. If the count on the test device is the 
same on the SUT, continue the test; else lower the test device 
traffic rate until the counts are the same. 


Record the packets timestamps at the transmitter and receiver 
ends of the test device for all VCC’s. 


Reporting Format: 


The results of the Two-point CDV/Mixed Load/Three VCC test SHOULD 
be reported in a form of text, graph, and histogram. 


The text results SHOULD display the numerical values of the CDV. 
The values given SHOULD include: time period of test in s, test 
VPI/VCI value, total number of cells transmitted and received on 
the given VPI/VCI during the test in positive integers, maximum 
and minimum CDV during the test in us, and peak-to-peak CDV in us. 


The graph results SHOULD display the cell delay values. The x- 
coordinate SHOULD be the test run time in either seconds, minutes 
or days depending on the total length of the test. The x- 
coordinate time SHOULD be configurable. The y-coordinate SHOULD 
be the cell delay in us. The integration time per point MUST be 
indicated. 


The histogram results SHOULD display the peak-to-peak cell delay. 
The x-coordinate SHOULD be the cell delay in us with at least 256 
bins. The y-coordinate SHOULD be the number of cells observed in 
each bin. 


The results MUST also indicate the packet size in octets, traffic 
rate in packets per second, and bearer class as generated by the 
test device. The VCC and VPI/VCI values MUST be indicated. The 
PCR, SCR, and MBS MUST be indicated. The bearer class of the 
created VCC MUST also be indicated. 


3.2.1.9. Two-point CDV/Mixed Load/Twelve VCCs 


Objective: To determine the SUT variation in cell transfer delay with 
twelve VCCs as defined in RFC 2761 "Terminology for ATM 
Benchmarking". 
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Procedure: 


1) 


5) 


Set up the SUT and test device using the bi-directional 
configuration. 


Configure the SUT and test device with twelve VCC’s. Each VCC 
MUST be defined as one of the Bearer classes for a total of four 
CBR, four UBR and four VBR VCC’s. Each VCC SHOULD contain one 
VPI/VCI. The VPI/VCI MUST not be one of the reserved ATM 
signaling channels (e.g., [0,5], [0,16]). 


Send a specific number of IP packets containing timestamps 
through the SUT via the defined test VCCs. Each generated VCC 
stream MUST match the corresponding VCC Bearer class. All of the 
VPI/VCI pairs will generate traffic at the same traffic rate. 
Since this test is not a throughput test, the rate should not be 
greater than 90% of line rate. The IP PDUs MUST be encapsulated 
in AALS. 


Count the IP packets that are transmitted by the SUT on all VCCs 
to verify connectivity and load. If the count on the test device 
is the same on the SUT, continue the test; else lower the test 
device traffic rate until the counts are the same. 


Record the packets timestamps at the transmitter and receiver 
ends of the test device for all VCCs. 


Reporting Format: 


The results of the Two-point CDV/Mixed Load/Twelve VCCs test 
SHOULD be reported in a form of text, graph, and histograms. 


The text results SHOULD display the numerical values of the CDV. 
The values given SHOULD include: time period of test in s, test 
VPI/VCI values, total number of cells transmitted and received on 
each VCC during the test in positive integers, maximum and minimum 
CDV on each VCC during the test in us, and peak-to-peak CDV on 
each VCC in us. 


The graph results SHOULD display the cell delay values. The x- 
coordinate SHOULD be the test run time in either seconds, minutes 
or days depending on the total length of the test. The x- 
coordinate time SHOULD be configurable. The y-coordinate SHOULD 
be the cell delay for each VCC in ms. There SHOULD be 12 curves 
on the graph, one curves indicated and labeled for each VCC. The 
integration time per point MUST be indicated. 
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The histograms SHOULD display the peak-to-peak cell delay. There 
will be one histogram for each VCC. The x-coordinate SHOULD be 
the cell delay in us with at least 256 bins. The y-coordinate 
SHOULD be the number of cells observed in each bin. 


The results MUST also indicate the packet size in octets, traffic 
rate in packets per second, and bearer class as generated by the 
test device. The VCC and VPI/VCI values MUST be indicated. The 
PCR, SCR, and MBS MUST be indicated. The bearer class of the 
created VCC MUST also be indicated. 


3.2.1.10. Two-point CDV/Mixed Load/Maximum VCCs 


Objective: To determine the SUT variation in cell transfer delay with 
the maximum number VCCs supported on the SUT as defined in RFC 2761 
"Terminology for ATM Benchmarking". 


Procedure: 


1) 


Set up the SUT and test device using the bi-directional 
configuration. 


Configure the SUT and test device with maximum number of VCCs 
supported on the SUT. For example, if the maximum number of VCCs 
supported on the SUT is 1024, define 256 VPIs with 4 VCIs per 
VPI. Each VCC MUST be defined as one of the Bearer classes for a 
total of (max VCC/3) CBR, (max VCC/3) UBR and (max VCC/3) VBR 
vec’s. If the maximum number of VCC’s is not divisible by 3, the 
total for each bearer class MUST be within 3 VCC’s of each other. 
The VPI/VCI MUST not be one of the reserved ATM signaling 
channels (e.g., [0,5], [0,16]). 


Send a specific number of IP packets containing timestamps 
through the SUT via the defined test VCCs. Each generated VCC 
stream MUST match the corresponding VCC Bearer class. All of the 
VPI/VCI pairs will generate traffic at the same traffic rate. 
Since this test is not a throughput test, the rate should not be 
greater than 90% of line rate. The IP PDUs MUST be encapsulated 
in AALS. 


Count the IP packets that are transmitted by the SUT on all VCCs 
to verify connectivity and load. If the count on the test device 
is the same on the SUT, continue the test; else lower the test 
device traffic rate until the counts are the same. 


Record the packets timestamps at the transmitter and receiver 
ends of the test device for all VCCs. 
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3 


2 


Reporting Format: 


EA 


The results of the Two-point CDV/Mixed Load/Maximum VCCs test 
SHOULD be reported in a form of text, graphs, and histograms. 


The text results SHOULD display the numerical values of the CDV. 
The values given SHOULD include: time period of test in s, test 
VPI/VCI values, total number of cells transmitted and received on 
each VCC during the test in positive integers, maximum and minimum 
CDV on each VCC during the test in us, and peak-to-peak CDV on 
each VCC in us. 


The graph results SHOULD display the cell delay values. There 
will be (Max number of VCCs/10) graphs, with 10 VCCs indicated on 
each graph. The x-coordinate SHOULD be the test run time in 
either seconds, minutes or days depending on the total length of 
the test. The x-coordinate time SHOULD be configurable. The y- 
coordinate SHOULD be the cell delay for each VCC in us. There 
SHOULD be no more than 10 curves on each graph, one curve 
indicated and labeled for each VCC. The integration time per 
point MUST be indicated. 


The histograms SHOULD display the peak-to-peak cell delay. There 
will be one histogram for each VCC. The x-coordinate SHOULD be 
the cell delay in us with at least 256 bins. The y-coordinate 
SHOULD be the number of cells observed in each bin. 


The results MUST also indicate the packet size in octets, traffic 
rate in packets per second, and bearer class as generated by the 
test device. The VCC and VPI/VCI values MUST be indicated. The 
PCR, SCR, and MBS MUST be indicated. The bearer class of the 
created VCC MUST also be indicated. 


Cell Error Ratio (CER) 


3.2.2.1. Test Setup 


The cell error ratio measurements assume that both the transmitter 
and receiver payload information is synchronized. Synchronization 
MUST be achieved by supplying a known bit pattern to both the 
transmitter and receiver. If this bit pattern is longer than the 
packet size, the receiver MUST synchronize with the transmitter 
before tests can be run. 
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3.2.2.2. CER/Steady Load/One VCC 


Objective: To determine the SUT ratio of errored cells on one VCC in 
a transmission in relation to the total cells sent as defined in RFC 
2761 "Terminology for ATM Benchmarking". 


Procedure: 


1) 


5) 


Set up the SUT and test device using the bi-directional 
configuration. 


Configure the SUT and test device with one VCC. The VCC SHOULD 
contain one VPI/VCI. The VCC MUST be configured as either a CBR, 
VBR, or UBR connection. The VPI/VCI MUST not be one of the 
reserved ATM signaling channels (e.g., [0,5], [0,16]). 


Send a specific number of IP packets containing one of the 
specified bit patterns at a constant rate through the SUT via the 
defined test VCC. Since this test is not a throughput test, the 
rate should not be greater than 90% of line rate. The IP PDUs 
MUST be encapsulated in AAL5. 


Count the IP packets that are transmitted by the SUT to verify 
connectivity and load. If the count on the test device is the 
same on the SUT, continue the test; else lower the test device 
traffic rate until the counts are the same. 


Record the number of bit errors at the receiver end of the test 
device. 


Reporting Format: 


The results of the CER/Steady Load/One VCC test SHOULD be reported 
in a form of text and graph. 


The text results SHOULD display the numerical values of the CER. 
The values given SHOULD include: time period of test in s, test 

VPI/VCI value, total number of cells transmitted and received on 
the given VPI/VCI during the test in positive integers, and the 

CER for the entire test. 


The graph results SHOULD display the cell error ratio values. The 
x-coordinate SHOULD be the test run time in either seconds, 
minutes or days depending on the total length of the test. The 
x-coordinate time SHOULD be configurable. The y-coordinate SHOULD 
be the CER. The integration time per point MUST be indicated. 
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The results MUST also indicate the packet size in octets, traffic 
rate in packets per second, and bearer class as generated by the 
test device. The VCC and VPI/VCI values MUST be indicated. The 
PCR, SCR, and MBS MUST be indicated. The bearer class of the 
created VCC MUST be indicated. The generated bit pattern MUST 
also be indicated. 


3.2.2.3. CER/Steady Load/Twelve VCCs 


Objective: To determine the SUT ratio of errored cells on twelve VCCs 
in a transmission in relation to the total cells sent as defined in 
RFC 2761 "Terminology for ATM Benchmarking". 


Procedure: 


1) 


5) 


Set up the SUT and test device using the bi-directional 
configuration. 


Configure the SUT and test device with twelve VCCs, using 1 VPI 

and 12 VCIs. The VCC’s MUST be configured as either a CBR, VBR, 
or UBR connection. The VPI/VCIs MUST not be one of the reserved 
ATM signaling channels (e.g., [0,5], [0,16]). 


Send a specific number of IP packets containing one of the 
specified bit patterns at a constant rate through the SUT via the 
defined test VCCs. All of the VPI/VCI pairs will generate 
traffic at the same traffic rate. Since this test is not a 
throughput test, the rate should not be greater than 90% of line 
rate. The IP PDUs MUST be encapsulated in AALD5. 


Count the IP packets that are transmitted by the SUT on all VCCs 
to verify connectivity and load. If the count on the test device 
is the same on the SUT, continue the test; else lower the test 
device traffic rate until the counts are the same. 


Record the number of bit errors at the receiver end of the test 
device for all VCCs. 


Reporting Format: 


The results of the CER/Steady Load/Twelve VCCs test SHOULD be 
reported in a form of text and graph. 


The text results SHOULD display the numerical values of the CER. 
The values given SHOULD include: time period of test in s, test 

VPI/VCI value, total number of cells transmitted and received on 
the given VPI/VCI during the test in positive integers, and the 

CER for the entire test. 
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The graph results SHOULD display the cell error ratio values. The 
x-coordinate SHOULD be the test run time in either seconds, 
minutes or days depending on the total length of the test. The 
x-coordinate time SHOULD be configurable. The y-coordinate SHOULD 
be the CER for each VCC. There should be 12 curves on the graph, 
on curve indicated and labeled for each VCC. The integration time 
per point MUST be indicated. 


The results MUST also indicate the packet size in octets, traffic 
rate in packets per second, and bearer class as generated by the 
test device. The VCC and VPI/VCI values MUST be indicated. The 
PCR, SCR, and MBS MUST be indicated. The bearer class of the 
created VCC MUST be indicated. The generated bit pattern MUST 
also be indicated. 


3.2.2.4. CER/Steady Load/Maximum VCCs 


Objective: To determine the SUT ratio of errored cells with the 
maximum number VCCs supported on the SUT in a transmission in 
relation to the total cells sent as defined in RFC 2761 "Terminology 
for ATM Benchmarking". 


Procedure: 


1) 


Set up the SUT and test device using the bi-directional 
configuration. 


Configure the SUT and test device with the maximum number of VCCs 
supported on the SUT. For example, if the maximum number of VCCs 
supported on the SUT is 1024, define 256 VPIs with 4 VCIs per 
VPI. The VCC’s MUST be configured as either a CBR, VBR, or UBR 
connection. The VPI/VCIs MUST not be one of the reserved ATM 
signaling channels (e.g., [0,5], [0,16]). 


Send a specific number of IP packets containing one of the 
specified bit patterns at a constant rate through the SUT via the 
defined test VCCs. All of the VPI/VCI pairs will generate 
traffic at the same traffic rate. Since this test is not a 
throughput test, the rate should not be greater than 90% of line 
rate. The IP PDUs MUST be encapsulated in AALD5. 


Count the IP packets that are transmitted by the SUT on all VCCs 
to verify connectivity and load. If the count on the test device 
is the same on the SUT, continue the test; else lower the test 
device traffic rate until the counts are the same. 


Record the number of bit errors at the receiver end of the test 
device for all VCCs. 
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Reporting Format: 


The results of the CER/Steady Load/Maximum VCCs test SHOULD be 
reported in a form of text and graph. 


The text results SHOULD display the numerical values of the CER. 
The values given SHOULD include: time period of test in s, test 

VPI/VCI value, total number of cells transmitted and received on 
the given VPI/VCI during the test in positive integers, and the 

CER for the entire test. 


The graph results SHOULD display the cell error ratio values. 
There will be (Max number of VCCs/10) graphs, with 10 VCCs 
indicated on each graph. The x-coordinate SHOULD be the test run 
time in either seconds, minutes or days depending on the total 
length of the test. The x-coordinate time SHOULD be configurable. 
The y-coordinate SHOULD be the CER for each VCC. There SHOULD be 
no more than 10 curves on each graph, one curve indicated and 
labeled for each VCC. The integration time per point MUST be 
indicated. 


The results MUST also indicate the packet size in octets, traffic 
rate in packets per second, and bearer class as generated by the 
test device. The VCC and VPI/VCI values MUST be indicated. The 
PCR, SCR, and MBS MUST be indicated. The bearer class of the 
created VCC MUST be indicated. The generated bit pattern MUST 
also be indicated. 


3.2.2.5. CER/Bursty VBR Load/One VCC 


Objective: To determine the SUT ratio of errored cells on one VCC in 
a transmission in relation to the total cells sent as defined in RFC 
2761 "Terminology for ATM Benchmarking". 


Procedure: 


1) 


Set up the SUT and test device using the bi-directional 
configuration. 


Configure the SUT and test device with one VCC. The VCC SHOULD 
contain one VPI/VCI. The VCC MUST be configured as either a CBR 
or VBR connection. The VPI/VCI MUST not be one of the reserved 
ATM signaling channels (e.g., [0,5], [0,16]). The PCR, SCR, and 
MBS must be configured using one of the specified traffic 
descriptors. 
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3) 


5) 


Send a specific number of IP packets containing one of the 
specified bit patterns at a specific VBR rate through the SUT via 
the defined test VCC. Since this test is not a throughput test, 
the rate should not be greater than 90% of line rate. The IP 
PDUs MUST be encapsulated in AAL5. 


Count the IP packets that are transmitted by the SUT to verify 
connectivity and load. If the count on the test device is the 
same on the SUT, continue the test; else lower the test device 
traffic rate until the counts are the same. 


Record the number of bit errors at the receiver end of the test 
device. 


Reporting Format: 


The results of the CER/Bursty VBR Load/One VCC test SHOULD be 
reported in a form of text and graph. 


The text results SHOULD display the numerical values of the CER. 
The values given SHOULD include: time period of test in s, test 

VPI/VCI value, total number of cells transmitted and received on 
the given VPI/VCI during the test in positive integers, and the 

CER for the entire test. 


The graph results SHOULD display the cell error ratio values. The 
x-coordinate SHOULD be the test run time in either seconds, 
minutes or days depending on the total length of the test. The 
x-coordinate time SHOULD be configurable. The y-coordinate SHOULD 
be the CER. The integration time per point MUST be indicated. 


The results MUST also indicate the packet size in octets, traffic 
rate in packets per second, and bearer class as generated by the 
test device. The VCC and VPI/VCI values MUST be indicated. The 
PCR, SCR, and MBS MUST be indicated. The bearer class of the 
created VCC MUST be indicated. The generated bit pattern MUST 
also be indicated. 


3.2.2.6. CER/Bursty VBR Load/Twelve VCCs 


Objective: To determine the SUT ratio of errored cells on twelve VCCs 
in a transmission in relation to the total cells sent as defined in 
RFC 2761 "Terminology for ATM Benchmarking". 


Procedure: 


1) 


Set up the SUT and test device using the bi-directional 
configuration. 
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2) 


5) 


Configure the SUT and test device with twelve VCCs, using 1 VPI 
and 12 VCIs. The VCC’s MUST be configured as either a CBR or VBR 
connection. The VPI/VCIs MUST not be one of the reserved ATM 
signaling channels (e.g., [0,5], [0,16]). The PCR, SCR, and MBS 
must be configured using one of the specified traffic 
descriptors. 


Send a specific number of IP packets containing one of the 
specified bit patterns at a specific VBR rate through the SUT via 
the defined test vVCCs. All of the VPI/VCI pairs will generate 
traffic at the same traffic rate. Since this test is not a 
throughput test, the rate should not be greater than 90% of line 
rate. The PCR, SCR, and MBS must be indicated. The IP PDUs MUST 
be encapsulated in AAL5. 


Count the IP packets that are transmitted by the SUT on all VCCs 
to verify connectivity and load. If the count on the test device 
is the same on the SUT, continue the test; else lower the test 
device traffic rate until the counts are the same. 


Record the number of bit errors at the receiver end of the test 
device for all VCCs. 


Reporting Format: 


The results of the CER/Bursty VBR Load/Twelve VCCs test SHOULD be 
reported in a form of text and graph. 


The text results SHOULD display the numerical values of the CER. 
The values given SHOULD include: time period of test in s, test 

VPI/VCI value, total number of cells transmitted and received on 
the given VPI/VCI during the test in positive integers, and the 

CER for the entire test. 


The graph results SHOULD display the cell error ratio values. The 
x-coordinate SHOULD be the test run time in either seconds, 
minutes or days depending on the total length of the test. The 
x-coordinate time SHOULD be configurable. The y-coordinate SHOULD 
be the CER for each VCC. There should be 12 curves on the graph, 
on curve indicated and labeled for each VCC. The integration time 
per point MUST be indicated. 


The results MUST also indicate the packet size in octets, traffic 
rate in packets per second, and bearer class as generated by the 
test device. The VCC and VPI/VCI values MUST be indicated. The 
PCR, SCR, and MBS MUST be indicated. The bearer class of the 
created VCC MUST be indicated. The generated bit pattern MUST 
also be indicated. 
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3.2.2.7. CER/Bursty VBR Load/Maximum VCCs 


Objective: To determine the SUT ratio of errored cells with the 
maximum number VCCs supported on the SUT in a transmission in 
relation to the total cells sent as defined in RFC 2761 "Terminology 
for ATM Benchmarking". 


Procedure: 


1) 


5) 


Set up the SUT and test device using the bi-directional 
configuration. 


Configure the SUT and test device with the maximum number of VCCs 
supported on the SUT. For example, if the maximum number of VCCs 
supported on the SUT is 1024, define 256 VPIs with 4 VCIs per 
VPI. The VCC’s MUST be configured as either a CBR or VBR 
connection. The VPI/VCIs MUST not be one of the reserved ATM 
signaling channels (e.g., [0,5], [0,16]). The PCR, SCR, and MBS 
must be configured using one of the specified traffic 
descriptors. 


Send a specific number of IP packets containing one of the 
specified bit patterns at a specific VBR rate through the SUT via 
the defined test VCCs. All of the VPI/VCI pairs will generate 
traffic at the same traffic rate. Since this test is not a 
throughput test, the rate should not be greater than 90% of line 
rate. The IP PDUs MUST be encapsulated in AALD5. 


Count the IP packets that are transmitted by the SUT on all VCCs 
to verify connectivity and load. If the count on the test device 
is the same on the SUT, continue the test; else lower the test 
device traffic rate until the counts are the same. 


Record the number of bit errors at the receiver end of the test 
device for all VCCs. 


Reporting Format: 


The results of the CER/Bursty VBR Load/Maximum VCCs test SHOULD be 
reported in a form of text and graph. 


The text results SHOULD display the numerical values of the CER. 
The values given SHOULD include: time period of test in s, test 

VPI/VCI value, total number of cells transmitted and received on 
the given VPI/VCI during the test in positive integers, and the 

CER for the entire test. 
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SEAT 


SEAE 


The graph results SHOULD display the cell error ratio values. 
There will be (Max number of VCCs/10) graphs, with 10 VCCs 
indicated on each graph. The x-coordinate SHOULD be the test run 
time in either seconds, minutes or days depending on the total 
length of the test. The x-coordinate time SHOULD be configurable. 
The y-coordinate SHOULD be the CER for each VCC. There SHOULD be 
no more than 10 curves on each graph, one curve indicated and 
labeled for each VCC. The integration time per point MUST be 
indicated. 


The results MUST also indicate the packet size in octets, traffic 
rate in packets per second, and bearer class as generated by the 
test device. The VCC and VPI/VCI values MUST be indicated. The 
PCR, SCR, and MBS MUST be indicated. The bearer class of the 
created VCC MUST be indicated. The generated bit pattern MUST 
also be indicated. 


Cell Loss Ratio (CLR) 


1. CLR/Steady Load/One VCC 


Objective: To determine the SUT ratio of lost cells on one VCC ina 
transmission in relation to the total cells sent as defined in RFC 
2761 "Terminology for ATM Benchmarking". 


Procedure: 


1) 


Set up the SUT and test device using the bi-directional 
configuration. 


Configure the SUT and test device with one VCC. The VCC SHOULD 
contain one VPI/VCI. The VCC MUST be configured as either a CBR, 
VBR, or UBR connection. The VPI/VCI MUST not be one of the 
reserved ATM signaling channels (e.g., [0,5], [0,16]). 


Send a specific number of IP packets at a specific constant rate 
through the SUT via the defined test VCC. Since this test is not 
a throughput test, the rate should not be greater than 90% of 
line rate. The IP PDUs MUST be encapsulated in AAL5. 


Count the IP packets that are transmitted by the SUT to verify 
connectivity and load. If the count on the test device is the 
same on the SUT, continue the test; else lower the test device 
traffic rate until the counts are the same. 


Record the number of cells transmitted and received on the test 
device. 
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Reporting Format: 


The results of the CLR/Steady Load/One VCC test SHOULD be reported 
in a form of text and graph. 


The text results SHOULD display the numerical values of the CLR. 
The values given SHOULD include: time period of test in s, test 

VPI/VCI value, total number of cells transmitted and received on 
the given VPI/VCI during the test in positive integers, and the 

CLR for the entire test. 


The graph results SHOULD display the Cell Loss ratio values. The 
x-coordinate SHOULD be the test run time in either seconds, 
minutes or days depending on the total length of the test. The 
x-coordinate time SHOULD be configurable. The y-coordinate SHOULD 
be the CLR. The integration time per point MUST be indicated. 


The results MUST also indicate the packet size in octets, traffic 
rate in packets per second, and bearer class as generated by the 
test device. The VCC and VPI/VCI values MUST be indicated. The 
PCR, SCR, and MBS MUST be indicated. The bearer class of the 
created VCC MUST also be indicated. 


3.2.3.2. CLR/Steady Load/Twelve VCCs 


Objective: To determine the SUT ratio of lost cells on twelve VCCs in 
a transmission in relation to the total cells sent as defined in RFC 
2761 "Terminology for ATM Benchmarking". 


Procedure: 


1) 


Set up the SUT and test device using the bi-directional 
configuration. 


Configure the SUT and test device with twelve VCCs, using 1 VPI 

and 12 VCIs. The VCC’s MUST be configured as either a CBR, VBR, 
or UBR connection. The VPI/VCIs MUST not be one of the reserved 
ATM signaling channels (e.g., [0,5], [0,16]). 


Send a specific number of IP packets at a specific constant rate 
through the SUT via the defined test VCCs. All of the VPI/VCI 
pairs will generate traffic at the same traffic rate. Since this 
test is not a throughput test, the rate should not be greater 
than 90% of line rate. The IP PDUs MUST be encapsulated in AAL5. 
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4) 


5) 


Count the IP packets that are transmitted by the SUT on all VCCs 
to verify connectivity and load. If the count on the test device 
is the same on the SUT, continue the test; else lower the test 
device traffic rate until the counts are the same. 


Record the number of cells transmitted and received per VCC on 
the test device. 


Reporting Format: 


The results of the CLR/Steady Load/Twelve VCCs test SHOULD be 
reported in a form of text and graph. 


The text results SHOULD display the numerical values of the CLR. 
The values given SHOULD include: time period of test in s, test 

VPI/VCI value, total number of cells transmitted and received on 
the given VPI/VCI during the test in positive integers, and the 

CLR for the entire test. 


The graph results SHOULD display the Cell Loss ratio values. The 
x-coordinate SHOULD be the test run time in either seconds, 
minutes or days depending on the total length of the test. The 
x-coordinate time SHOULD be configurable. The y-coordinate SHOULD 
be the CLR for each VCC. There should be 12 curves on the graph, 
on curve indicated and labeled for each VCC. The integration time 
per point MUST be indicated. 


The results MUST also indicate the packet size in octets, traffic 
rate in packets per second, and bearer class as generated by the 
test device. The VCC and VPI/VCI values MUST be indicated. The 
PCR, SCR, and MBS MUST be indicated. The bearer class of the 
created VCC MUST also be indicated. 


3.2.3.3. CLR/Steady Load/Maximum VCCs 


Objective: To determine the SUT ratio of lost cells with the maximum 
number VCCs supported on the SUT in a transmission in relation to the 
total cells sent as defined in RFC 2761 "Terminology for ATM 
Benchmarking". 


Procedure: 


1) 


Set up the SUT and test device using the bi-directional 
configuration. 


Configure the SUT and test device with the maximum number of VCCs 
supported on the SUT. For example, if the maximum number of VCCs 
supported on the SUT is 1024, define 256 VPIs with 4 VCIs per 
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5) 


VPI. The VCC’s MUST be configured as either a CBR, VBR, or UBR 
connection. The VPI/VCIs MUST not be one of the reserved ATM 
signaling channels (e.g., [0,5], [0,16]). 


Send a specific number of IP packets at a specific constant rate 
through the SUT via the defined test VCCs. All of the VPI/VCI 
pairs will generate traffic at the same traffic rate. Since this 
test is not a throughput test, the rate should not be greater 
than 90% of line rate. The IP PDUs MUST be encapsulated in AAL5. 


Count the IP packets that are transmitted by the SUT on all VCCs 
to verify connectivity and load. If the count on the test device 
is the same on the SUT, continue the test; else lower the test 
device traffic rate until the counts are the same. 


Record the number of cells transmitted and received per VCC on 
the test device. 


Reporting Format: 


The results of the CLR/Steady Load/Maximum VCCs test SHOULD be 
reported in a form of text and graph. 


The text results SHOULD display the numerical values of the CLR. 
The values given SHOULD include: time period of test in s, test 

VPI/VCI value, total number of cells transmitted and received on 
the given VPI/VCI during the test in positive integers, and the 

CLR for the entire test. 


The graph results SHOULD display the Cell Loss ratio values. 

There will be (Max number of VCCs/10) graphs, with 10 VCCs 
indicated on each graph. The x-coordinate SHOULD be the test run 
time in either seconds, minutes or days depending on the total 
length of the test. The x-coordinate time SHOULD be configurable. 
The y-coordinate SHOULD be the CLR for each VCC. There SHOULD be 
no more than 10 curves on each graph, one curve indicated and 
labeled for each VCC. The integration time per point MUST be 
indicated. 


The results MUST also indicate the packet size in octets, traffic 
rate in packets per second, and bearer class as generated by the 
test device. The VCC and VPI/VCI values MUST be indicated. The 
PCR, SCR, and MBS MUST be indicated. The bearer class of the 
created VCC MUST also be indicated. 
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3.2.3.4. CLR/Bursty VBR Load/One VCC 


Objective: To determine the SUT ratio of lost cells on one VCC ina 
transmission in relation to the total cells sent as defined in RFC 
2761 "Terminology for ATM Benchmarking". 


Procedure: 


1) 


5) 


Set up the SUT and test device using the bi-directional 
configuration. 


Configure the SUT and test device with one VCC. The VCC SHOULD 
contain one VPI/VCI. The VCC MUST be configured as either a CBR 
or VBR connection. The VPI/VCI MUST not be one of the reserved 
ATM signaling channels (e.g., [0,5], [0,16]). The PCR, SCR, and 
MBS must be configured using one of the specified traffic 
descriptors. 


Send a specific number of IP packets containing one of the 
specified bit patterns at a specific rate through the SUT via the 
defined test VCC. Since this test is not a throughput test, the 
rate should not be greater than 90% of line rate. The IP PDUs 
MUST be encapsulated in AAL5. 


Count the IP packets that are transmitted by the SUT to verify 
connectivity and load. If the count on the test device is the 
same on the SUT, continue the test; else lower the test device 
traffic rate until the counts are the same. 


Record the number of cells transmitted and received on the test 
device. 


Reporting Format: 


The results of the CLR/Bursty VBR Load/One VCC test SHOULD be 
reported in a form of text and graph. 


The text results SHOULD display the numerical values of the CLR. 
The values given SHOULD include: time period of test in s, test 

VPI/VCI value, total number of cells transmitted and received on 
the given VPI/VCI during the test in positive integers, and the 

CLR for the entire test. 


The graph results SHOULD display the Cell Loss ratio values. The 
x-coordinate SHOULD be the test run time in either seconds, 
minutes or days depending on the total length of the test. The 
x-coordinate time SHOULD be configurable. The y-coordinate SHOULD 
be the CLR. The integration time per point MUST be indicated. 
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The results MUST also indicate the packet size in octets, traffic 
rate in packets per second, and bearer class as generated by the 
test device. The VCC and VPI/VCI values MUST be indicated. The 
PCR, SCR, and MBS MUST be indicated. The bearer class of the 
created VCC MUST also be indicated. 


3.2.3.5. CLR/Bursty VBR Load/Twelve VCCs 


Objective: To determine the SUT ratio of lost cells on twelve VCCs in 
a transmission in relation to the total cells sent as defined in RFC 
2761 "Terminology for ATM Benchmarking". 


Procedure: 


1) 


5) 


Set up the SUT and test device using the bi-directional 
configuration. 


Configure the SUT and test device with twelve VCCs, using 1 VPI 
and 12 VCIs. The VCC MUST be configured as either a CBR or VBR 
connection. The VPI/VCIs MUST not be one of the reserved ATM 
signaling channels (e.g., [0,5], [0,16]). The PCR, SCR, and MBS 
must be configured using one of the specified traffic 
descriptors. 


Send a specific number of IP packets containing one of the 
specified bit patterns at a specific rate through the SUT via the 
defined test VCCs. All of the VPI/VCI pairs will generate 
traffic at the same traffic rate. Since this test is not a 
throughput test, the rate should not be greater than 90% of line 
rate. The PCR, SCR, and MBS must be indicated. The IP PDUs MUST 
be encapsulated in AAL5. 


Count the IP packets that are transmitted by the SUT on all VCCs 
to verify connectivity and load. If the count on the test device 
is the same on the SUT, continue the test; else lower the test 
device traffic rate until the counts are the same. 


Record the number of cells transmitted and received per VCC on 
the test device. 


Reporting Format: 


The results of the CLR/Bursty VBR Load/Twelve VCCs test SHOULD be 
reported in a form of text and graph. 


The text results SHOULD display the numerical values of the CLR. 
The values given SHOULD include: time period of test in s, test 
VPI/VCI value, total number of cells transmitted and received on 
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the given VPI/VCI during the test in positive integers, and the 
CLR for the entire test. 


The graph results SHOULD display the Cell Loss ratio values. The 
x-coordinate SHOULD be the test run time in either seconds, 
minutes or days depending on the total length of the test. The 
x-coordinate time SHOULD be configurable. The y-coordinate SHOULD 
be the CLR for each VCC. There should be 12 curves on the graph, 
on curve indicated and labeled for each VCC. The integration time 
per point MUST be indicated. 


The results MUST also indicate the packet size in octets, traffic 
rate in packets per second, and bearer class as generated by the 
test device. The VCC and VPI/VCI values MUST be indicated. The 
PCR, SCR, and MBS MUST be indicated. The bearer class of the 
created VCC MUST also be indicated. 


3.2.3.6. CLR/Bursty VBR Load/Maximum VCCs 


Objective: To determine the SUT ratio of lost cells with the maximum 
number VCCs supported on the SUT in a transmission in relation to the 
total cells sent as defined in RFC 2761 "Terminology for ATM 
Benchmarking". 


Procedure: 


1) 


Set up the SUT and test device using the bi-directional 
configuration. 


Configure the SUT and test device with the maximum number of VCCs 
supported on the SUT. For example, if the maximum number of VCCs 
supported on the SUT is 1024, define 256 VPIs with 4 VCIs per 
VPI. The VCC MUST be configured as either a CBR or VBR 
connection. The VPI/VCIs MUST not be one of the reserved ATM 
signaling channels (e.g., [0,5], [0,16]). The PCR, SCR, and MBS 
must be configured using one of the specified traffic 
descriptors. 


Send a specific number of IP packets containing one of the 
specified bit patterns at a specific rate through the SUT via the 
defined test VCCs. All of the VPI/VCI pairs will generate 
traffic at the same traffic rate. Since this test is not a 
throughput test, the rate should not be greater than 90% of line 
rate. The IP PDUs MUST be encapsulated in AALD5. 
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3 


a2 


4) 


5) 


Count the IP packets that are transmitted by the SUT on all VCCs 
to verify connectivity and load. If the count on the test device 
is the same on the SUT, continue the test; else lower the test 
device traffic rate until the counts are the same. 


Record the number of cells transmitted and received per VCC on 
the test device. 


Reporting Format: 


4. 


The results of the CLR/Bursty VBR Load/Maximum VCCs test SHOULD be 
reported in a form of text and graph. 


The text results SHOULD display the numerical values of the CLR. 
The values given SHOULD include: time period of test in s, test 

VPI/VCI value, total number of cells transmitted and received on 
the given VPI/VCI during the test in positive integers, and the 

CLR for the entire test. 


The graph results SHOULD display the Cell Loss ratio values. 

There will be (Max number of VCCs/10) graphs, with 10 VCCs 
indicated on each graph. The x-coordinate SHOULD be the test run 
time in either seconds, minutes or days depending on the total 
length of the test. The x-coordinate time SHOULD be configurable. 
The y-coordinate SHOULD be the CLR for each VCC. There SHOULD be 
no more than 10 curves on each graph, one curve indicated and 
labeled for each VCC. The integration time per point MUST be 
indicated. 


The results MUST also indicate the packet size in octets, traffic 
rate in packets per second, and bearer class as generated by the 
test device. The VCC and VPI/VCI values MUST be indicated. The 
PCR, SCR, and MBS MUST be indicated. The bearer class of the 
created VCC MUST also be indicated. 


Cell Misinsertion Rate (CMR) 


3.2.4.1. CMR/Steady Load/One VCC 


Objective: To determine the SUT ratio of cell misinsertion on one VCC 
in a transmission in relation to the total cells sent as defined in 
RFC 2761 "Terminology for ATM Benchmarking". 


Procedure: 


1) 


Set up the SUT and test device using the bi-directional 
configuration. 
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2) 


5) 


Configure the SUT and test device with one VCC. The VCC MUST be 
configured as either a CBR, VBR, or UBR connection. The VCC 
SHOULD contain one VPI/VCI. The VPI/VCI MUST not be one of the 
reserved ATM signaling channels (e.g., [0,5], [0,16]). 


Send a specific number of IP packets at a specific constant rate 
through the SUT via the defined test VCC. Since this test is not 
a throughput test, the rate should not be greater than 90% of 
line rate. The IP PDUs MUST be encapsulated in AAL5. 


Count the IP packets that are transmitted by the SUT to verify 
connectivity and load. If the count on the test device is the 
same on the SUT, continue the test; else lower the test device 
traffic rate until the counts are the same. 


Record the number of cell misinsertion errors at the receiver end 
of the test device. 


Reporting Format: 


The results of the CMR/Steady Load/One VCC test SHOULD be reported 
in a form of text and graph. 


The text results SHOULD display the numerical values of the CMR. 
The values given SHOULD include: time period of test in s, test 

VPI/VCI value, total number of cells transmitted and received on 
the given VPI/VCI during the test in positive integers, and the 

CMR for the entire test. 


The graph results SHOULD display the Cell misinsertion rate 
values. The x-coordinate SHOULD be the test run time in either 
seconds, minutes or days depending on the total length of the 
test. The x-coordinate time SHOULD be configurable. The y- 
coordinate SHOULD be the CMR. The integration time per point MUST 
be indicated. 


The results MUST also indicate the packet size in octets, traffic 
rate in packets per second, and bearer class as generated by the 
test device. The VCC and VPI/VCI values MUST be indicated. The 
PCR, SCR, and MBS MUST be indicated. The bearer class of the 
created VCC MUST also be indicated. 


3.2.4.2. CMR/Steady Load/Twelve VCCs 


Objective: To determine the SUT rate of misinserted cells on twelve 
vcCs in a transmission in relation to the total cells sent as defined 
in RFC 2761 "Terminology for ATM Benchmarking". 
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Procedure: 


1) 


5) 


Set up the SUT and test device using the bi-directional 
configuration. 


Configure the SUT and test device with twelve VCCs, using 1 VPI 

and 12 VCIs. The VCC’s MUST be configured as either a CBR, VBR, 
or UBR connection. The VPI/VCIs MUST not be one of the reserved 
ATM signaling channels (e.g., [0,5], [0,16]). 


Send a specific number of IP packets at a specific constant rate 
through the SUT via the defined test VCCs. All of the VPI/VCI 
pairs will generate traffic at the same traffic rate. Since this 
test is not a throughput test, the rate should not be greater 
than 90% of line rate. The IP PDUs MUST be encapsulated in AAL5. 


Count the IP packets that are transmitted by the SUT on all VCCs 
to verify connectivity and load. If the count on the test device 
is the same on the SUT, continue the test; else lower the test 
device traffic rate until the counts are the same. 


Record the number of cell misinsertion errors at the receiver end 
of the test device per VCC. 


Reporting Format: 


The results of the CMR/Steady Load/Twelve VCCs test SHOULD be 
reported in a form of text and graph. 


The text results SHOULD display the numerical values of the CMR. 
The values given SHOULD include: time period of test in s, test 

VPI/VCI value, total number of cells transmitted and received on 
the given VPI/VCI during the test in positive integers, and the 

CMR for the entire test. 


The graph results SHOULD display the Cell misinsertion rate 
values. The x-coordinate SHOULD be the test run time in either 
seconds, minutes or days depending on the total length of the 
test. The x-coordinate time SHOULD be configurable. The y- 
coordinate SHOULD be the CMR for each VCC. There should be 12 
curves on the graph, on curve indicated and labeled for each VCC. 
The integration time per point MUST be indicated. 


The results MUST also indicate the packet size in octets, traffic 
rate in packets per second, and bearer class as generated by the 
test device. The VCC and VPI/VCI values MUST be indicated. The 
PCR, SCR, and MBS MUST be indicated. The bearer class of the 
created VCC MUST also be indicated. 
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3.2.4.3. CMR/Steady Load/Maximum VCCs 


Objective: To determine the SUT rate of misinserted cells with the 
maximum number VCCs supported on the SUT in a transmission in 
relation to the total cells sent as defined in RFC 2761 "Terminology 
for ATM Benchmarking". 


Procedure: 


1) 


5) 


Set up the SUT and test device using the bi-directional 
configuration. 


Configure the SUT and test device with the maximum number of VCCs 
supported on the SUT. For example, if the maximum number of VCCs 
supported on the SUT is 1024, define 256 VPIs with 4 VCIs per 
VPI. The VCC’s MUST be configured as either a CBR, VBR, or UBR 
connection. The VPI/VCIs MUST not be one of the reserved ATM 
signaling channels (e.g., [0,5], [0,16]). 


Send a specific number of IP packets at a specific constant rate 
through the SUT via the defined test VCCs. All of the VPI/VCI 
pairs will generate traffic at the same traffic rate. Since this 
test is not a throughput test, the rate should not be greater 
than 90% of line rate. The IP PDUs MUST be encapsulated in AAL5. 


Count the IP packets that are transmitted by the SUT on all VCCs 
to verify connectivity and load. If the count on the test device 
is the same on the SUT, continue the test; else lower the test 
device traffic rate until the counts are the same. 


Record the number of cell misinsertion errors at the receiver end 
of the test device per VCC. 


Reporting Format: 


The results of the CMR/Steady Load/Maximum VCCs test SHOULD be 
reported in a form of text and graph. 


The text results SHOULD display the numerical values of the CMR. 
The values given SHOULD include: time period of test in s, test 

VPI/VCI value, total number of cells transmitted and received on 
the given VPI/VCI during the test in positive integers, and the 

CMR for the entire test. 


The graph results SHOULD display the Cell misinsertion rate 
values. There will be (Max number of VCCs/10) graphs, with 10 
VCCs indicated on each graph. The x-coordinate SHOULD be the test 
run time in either seconds, minutes or days depending on the total 
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length of the test. The x-coordinate time SHOULD be configurable. 
The y-coordinate SHOULD be the CMR for each VCC. There SHOULD be 
no more than 10 curves on each graph, one curve indicated and 
labeled for each VCC. The integration time per point MUST be 
indicated. 


The results MUST also indicate the packet size in octets, traffic 
rate in packets per second, and bearer class as generated by the 
test device. The VCC and VPI/VCI values MUST be indicated. The 
PCR, SCR, and MBS MUST be indicated. The bearer class of the 
created VCC MUST also be indicated. 


3.2.4.4. CMR/Bursty VBR Load/One VCC 


Objective: To determine the SUT rate of misinserted cells on one VCC 
in a transmission in relation to the total cells sent as defined in 
RFC 2761 "Terminology for ATM Benchmarking". 


Procedure: 


1) Set up the SUT and test device using the bi-directional 
configuration. 


2) Configure the SUT and test device with one VCC. The VCC SHOULD 
contain one VPI/VCI. The VCC MUST be configured as either a CBR 
or VBR connection. The VPI/VCI MUST not be one of the reserved 
ATM signaling channels (e.g., [0,5], [0,16]). The PCR, SCR, and 
MBS must be configured using one of the specified traffic 
descriptors. 


3) Send a specific number of IP packets containing one of the 
specified bit patterns at a specific rate through the SUT via the 
defined test VCC. Since this test is not a throughput test, the 
rate should not be greater than 90% of line rate. The IP PDUs 
MUST be encapsulated in AAL5. 


4) Count the IP packets that are transmitted by the SUT to verify 
connectivity and load. If the count on the test device is the 
same on the SUT, continue the test; else lower the test device 
traffic rate until the counts are the same. 


5) Record the number of cell misinsertion errors at the receiver end 
of the test device. 


Reporting Format: 


The results of the CMR/Bursty VBR Load/One VCC test SHOULD be 
reported in a form of text and graph. 
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The text results SHOULD display the numerical values of the CMR. 
The values given SHOULD include: time period of test in s, test 

VPI/VCI value, total number of cells transmitted and received on 
the given VPI/VCI during the test in positive integers, and the 

CMR for the entire test. 


The graph results SHOULD display the Cell misinsertion rate 
values. The x-coordinate SHOULD be the test run time in either 
seconds, minutes or days depending on the total length of the 
test. The x-coordinate time SHOULD be configurable. The y- 
coordinate SHOULD be the CMR. The integration time per point MUST 
be indicated. 


The results MUST also indicate the packet size in octets, traffic 
rate in packets per second, and bearer class as generated by the 
test device. The VCC and VPI/VCI values MUST be indicated. The 
PCR, SCR, and MBS MUST be indicated. The bearer class of the 
created VCC MUST also be indicated. 


3.2.4.5. CMR/Bursty VBR Load/Twelve VCCs 


Objective: To determine the SUT rate of misinserted cells on twelve 
vcCs in a transmission in relation to the total cells sent as defined 
in RFC 2761 "Terminology for ATM Benchmarking". 


Procedure: 


1) 


Set up the SUT and test device using the bi-directional 
configuration. 


Configure the SUT and test device with twelve VCCs, using 1 VPI 
and 12 VCIs. The VCC’s MUST be configured as either a CBR or VBR 
connection. The VPI/VCIs MUST not be one of the reserved ATM 
signaling channels (e.g., [0,5], [0,16]). The PCR, SCR, and MBS 
must be configured using one of the specified traffic 
descriptors. 


Send a specific number of IP packets containing one of the 
specified bit patterns at a specific rate through the SUT via the 
defined test VCCs. All of the VPI/VCI pairs will generate 
traffic at the same traffic rate. Since this test is not a 
throughput test, the rate should not be greater than 90% of line 
rate. The PCR, SCR, and MBS must be indicated. The IP PDUs MUST 
be encapsulated in AALS. 
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4) Count the IP packets that are transmitted by the SUT on all VCCs 
to verify connectivity and load. If the count on the test device 
is the same on the SUT, continue the test; else lower the test 
device traffic rate until the counts are the same. 


5) Record the number of cell misinsertion errors at the receiver end 
of the test device per VCC. 


Reporting Format: 


The results of the CMR/Bursty VBR Load/Twelve VCCs test SHOULD be 
reported in a form of text and graph. 


The text results SHOULD display the numerical values of the CMR. 
The values given SHOULD include: time period of test in s, test 

VPI/VCI value, total number of cells transmitted and received on 
the given VPI/VCI during the test in positive integers, and the 

CMR for the entire test. 


The graph results SHOULD display the Cell misinsertion rate 
values. The x-coordinate SHOULD be the test run time in either 
seconds, minutes or days depending on the total length of the 
test. The x-coordinate time SHOULD be configurable. The y- 
coordinate SHOULD be the CMR for each VCC. There should be 12 
curves on the graph, on curve indicated and labeled for each VCC. 
The integration time per point MUST be indicated. 


The results MUST also indicate the packet size in octets, traffic 
rate in packets per second, and bearer class as generated by the 
test device. The VCC and VPI/VCI values MUST be indicated. The 
PCR, SCR, and MBS MUST be indicated. The bearer class of the 
created VCC MUST also be indicated. 


3.2.4.6. CMR/Bursty VBR Load/Maximum VCCs 


Objective: To determine the SUT rate of misinserted cells with the 
maximum number VCCs supported on the SUT in a transmission in 
relation to the total cells sent as defined in RFC 2761 "Terminology 
for ATM Benchmarking". 


Procedure: 


1) Set up the SUT and test device using the bi-directional 
configuration. 


2) Configure the SUT and test device with the maximum number of VCCs 


supported on the SUT. For example, if the maximum number of VCCs 
supported on the SUT is 1024, define 256 VPIs with 4 VCIs per 
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5) 


VPI. The VCC’s MUST be configured as either a CBR or VBR 
connection. The VPI/VCIs MUST not be one of the reserved ATM 
signaling channels (e.g., [0,5], [0,16]). The PCR, SCR, and MBS 
must be configured using one of the specified traffic 
descriptors. 


Send a specific number of IP packets containing one of the 
specified bit patterns at a specific rate through the SUT via the 
defined test VCCs. All of the VPI/VCI pairs will generate 
traffic at the same traffic rate. Since this test is not a 
throughput test, the rate should not be greater than 90% of line 
rate. The IP PDUs MUST be encapsulated in AALD5. 


Count the IP packets that are transmitted by the SUT on all VCCs 
to verify connectivity and load. If the count on the test device 
is the same on the SUT, continue the test; else lower the test 
device traffic rate until the counts are the same. 


Record the number of cell misinsertion errors at the receiver end 
of the test device per VCC. 


Reporting Format: 


The results of the CMR/Bursty VBR Load/Maximum VCCs test SHOULD be 
reported in a form of text and graph. 


The text results SHOULD display the numerical values of the CMR. 
The values given SHOULD include: time period of test in s, test 

VPI/VCI value, total number of cells transmitted and received on 
the given VPI/VCI during the test in positive integers, and the 

CMR for the entire test. 


The graph results SHOULD display the Cell misinsertion rate 
values. There will be (Max number of VCCs/10) graphs, with 10 
VCCs indicated on each graph. The x-coordinate SHOULD be the test 
run time in either seconds, minutes or days depending on the total 
length of the test. The x-coordinate time SHOULD be configurable. 
The y-coordinate SHOULD be the CMR for each VCC. There SHOULD be 
no more than 10 curves on each graph, one curve indicated and 
labeled for each VCC. The integration time per point MUST be 
indicated. 


The results MUST also indicate the packet size in octets, traffic 
rate in packets per second, and bearer class as generated by the 
test device. The VCC and VPI/VCI values MUST be indicated. The 
PCR, SCR, and MBS MUST be indicated. The bearer class of the 
created VCC MUST also be indicated. 
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S62 Dis 


CRC Error Ratio (CRC-ER) 


3.2.5.1. CRC-ER/Steady Load/One VCC 


Objective: To determine the SUT ratio of CRC errors on one VCC ina 
transmission in relation to the total cells sent as defined in RFC 
2761 "Terminology for ATM Benchmarking". 


Procedure: 


1) 


5) 


Set up the SUT and test device using the bi-directional 
configuration. 


Configure the SUT and test device with one VCC. The VCC SHOULD 
contain one VPI/VCI. The VCC MUST be configured as either a CBR, 
VBR, or UBR connection. The VPI/VCI MUST not be one of the 
reserved ATM signaling channels (e.g., [0,5], [0,16]). 


Send a specific number of IP packets at a specific constant rate 
through the SUT via the defined test VCC. Since this test is not 
a throughput test, the rate should not be greater than 90% of 
line rate. The IP PDUs MUST be encapsulated in AAL5. 


Count the IP packets that are transmitted by the SUT to verify 
connectivity and load. If the count on the test device is the 
same on the SUT, continue the test; else lower the test device 
traffic rate until the counts are the same. 


Record the number of CRC errored cells received on the test 
device. 


Reporting Format: 


The results of the CRC-ER/Steady Load/One VCC test SHOULD be 
reported in a form of text and graph. 


The text results SHOULD display the numerical values of the CRC- 
ER. The values given SHOULD include: time period of test in s, 
test VPI/VCI value, total number of cells transmitted and received 
on the given VPI/VCI during the test in positive integers, and the 
CRC-ER for the entire test. 


The graph results SHOULD display the CRC Error ratio values. The 
x-coordinate SHOULD be the test run time in either seconds, 
minutes or days depending on the total length of the test. The 
x-coordinate time SHOULD be configurable. The y-coordinate SHOULD 
be the CRC-ER. The integration time per point MUST be indicated. 
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The results MUST also indicate the packet size in octets, traffic 
rate in packets per second, and bearer class as generated by the 
test device. The VCC and VPI/VCI values MUST be indicated. The 
PCR, SCR, and MBS MUST be indicated. The bearer class of the 
created VCC MUST also be indicated. 


3.2.5.2. CRC-ER/Steady Load/Twelve VCCs 


Objective: To determine the SUT ratio of lost cells on twelve VCCs in 
a transmission in relation to the total cells sent as defined in RFC 
2761 "Terminology for ATM Benchmarking". 


Procedure: 


1) 


5) 


Set up the SUT and test device using the bi-directional 
configuration. 


Configure the SUT and test device with twelve VCCs, using 1 VPI 

and 12 VCIs. The VCC’s MUST be configured as either a CBR, VBR, 
or UBR connection. The VPI/VCIs MUST not be one of the reserved 
ATM signaling channels (e.g., [0,5], [0,16]). 


Send a specific number of IP packets at a specific constant rate 
through the SUT via the defined test VCCs. All of the VPI/VCI 
pairs will generate traffic at the same traffic rate. Since this 
test is not a throughput test, the rate should not be greater 
than 90% of line rate. The IP PDUs MUST be encapsulated in AAL5. 


Count the IP packets that are transmitted by the SUT on all VCCs 
to verify connectivity and load. If the count on the test device 
is the same on the SUT, continue the test; else lower the test 
device traffic rate until the counts are the same. 


Record the number of CRC errored cells received per VCC on the 
test device. 


Reporting Format: 


The results of the CRC-ER/Steady Load/Twelve VCCs test SHOULD be 
reported in a form of text and graph. 


The text results SHOULD display the numerical values of the CRC- 
ER. The values given SHOULD include: time period of test in s, 
test VPI/VCI value, total number of cells transmitted and received 
on the given VPI/VCI during the test in positive integers, and the 
CRC-ER for the entire test. 
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The graph results SHOULD display the CRC Error ratio values. The 
x-coordinate SHOULD be the test run time in either seconds, 
minutes or days depending on the total length of the test. The 
x-coordinate time SHOULD be configurable. The y-coordinate SHOULD 
be the CRC-ER for each VCC. There should be 12 curves on the 
graph, on curve indicated and labeled for each VCC. The 
integration time per point MUST be indicated. 


The results MUST also indicate the packet size in octets, traffic 
rate in packets per second, and bearer class as generated by the 
test device. The VCC and VPI/VCI values MUST be indicated. The 
PCR, SCR, and MBS MUST be indicated. The bearer class of the 
created VCC MUST also be indicated. 


3.2.5.3. CRC-ER/Steady Load/Maximum VCCs 


Objective: To determine the SUT ratio of lost cells with the maximum 
number VCCs supported on the SUT in a transmission in relation to the 
total cells sent as defined in RFC 2761 "Terminology for ATM 
Benchmarking". 


Procedure: 


1) 


Set up the SUT and test device using the bi-directional 
configuration. 


Configure the SUT and test device with the maximum number of VCCs 
supported on the SUT. For example, if the maximum number of VCCs 
supported on the SUT is 1024, define 256 VPIs with 4 VCIs per 
VPI. The VCC’s MUST be configured as either a CBR, VBR, or UBR 
connection. The VPI/VCIs MUST not be one of the reserved ATM 
signaling channels (e.g., [0,5], [0,16]). 


Send a specific number of IP packets at a specific constant rate 
through the SUT via the defined test VCCs. All of the VPI/VCI 
pairs will generate traffic at the same traffic rate. Since this 
test is not a throughput test, the rate should not be greater 
than 90% of line rate. The IP PDUs MUST be encapsulated in AAL5. 


Count the IP packets that are transmitted by the SUT on all VCCs 
to verify connectivity and load. If the count on the test device 
is the same on the SUT, continue the test; else lower the test 
device traffic rate until the counts are the same. 


Record the number of CRC errored cells received per VCC on the 
test device. 
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Reporting Format: 


The results of the CRC-ER/Steady Load/Maximum VCCs test SHOULD be 
reported in a form of text and graph. 


The text results SHOULD display the numerical values of the CRC- 
ER. The values given SHOULD include: time period of test in s, 
test VPI/VCI value, total number of cells transmitted and received 
on the given VPI/VCI during the test in positive integers, and the 
CRC-ER for the entire test. 


The graph results SHOULD display the CRC Error ratio values. 

There will be (Max number of VCCs/10) graphs, with 10 VCCs 
indicated on each graph. The x-coordinate SHOULD be the test run 
time in either seconds, minutes or days depending on the total 
length of the test. The x-coordinate time SHOULD be configurable. 
The y-coordinate SHOULD be the CRC-ER for each VCC. There SHOULD 
be no more than 10 curves on each graph, one curve indicated and 
labeled for each VCC. The integration time per point MUST be 
indicated. 


The results MUST also indicate the packet size in octets, traffic 
rate in packets per second, and bearer class as generated by the 
test device. The VCC and VPI/VCI values MUST be indicated. The 
PCR, SCR, and MBS MUST be indicated. The bearer class of the 
created VCC MUST also be indicated. 


3.2.5.4. CRC-ER/Bursty VBR Load/One VCC 


Objective: To determine the SUT ratio of lost cells on one VCC ina 
transmission in relation to the total cells sent as defined in RFC 
2761 "Terminology for ATM Benchmarking". 


Procedure: 


1) 


Set up the SUT and test device using the bi-directional 
configuration. 


Configure the SUT and test device with one VCC. The VCC SHOULD 
contain one VPI/VCI. The VCC MUST be configured as either a CBR 
or VBR connection. The VPI/VCI MUST not be one of the reserved 
ATM signaling channels (e.g., [0,5], [0,16]). The PCR, SCR, and 
MBS must be configured using one of the specified traffic 
descriptors. 


Send a specific number of IP packets containing one of the 
specified bit patterns at a specific rate through the SUT via the 
defined test VCC. Since this test is not a throughput test, the 
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5) 


rate should not be greater than 90% of line rate. The IP PDUs 
MUST be encapsulated in AAL5. 


Count the IP packets that are transmitted by the SUT to verify 
connectivity and load. If the count on the test device is the 
same on the SUT, continue the test; else lower the test device 
traffic rate until the counts are the same. 


Record the number of CRC errored cells received per VCC on the 
test device. 


Reporting Format: 


The results of the CRC-ER/Bursty VBR Load/One VCC test SHOULD be 
reported in a form of text and graph. 


The text results SHOULD display the numerical values of the CRC- 
ER. The values given SHOULD include: time period of test in s, 
test VPI/VCI value, total number of cells transmitted and received 
on the given VPI/VCI during the test in positive integers, and the 
CRC-ER for the entire test. 


The graph results SHOULD display the CRC Error ratio values. The 
x-coordinate SHOULD be the test run time in either seconds, 
minutes or days depending on the total length of the test. The 
x-coordinate time SHOULD be configurable. The y-coordinate SHOULD 
be the CRC-ER. The integration time per point MUST be indicated. 


The results MUST also indicate the packet size in octets, traffic 
rate in packets per second, and bearer class as generated by the 
test device. The VCC and VPI/VCI values MUST be indicated. The 
PCR, SCR, and MBS MUST be indicated. The bearer class of the 
created VCC MUST also be indicated. 


3.2.5.5. CRC-ER/Bursty VBR Load/Twelve VCCs 


Objective: To determine the SUT ratio of lost cells on twelve VCCs in 
a transmission in relation to the total cells sent as defined in RFC 
2761 "Terminology for ATM Benchmarking". 


Procedure: 


1) 


Set up the SUT and test device using the bi-directional 
configuration. 


Configure the SUT and test device with twelve VCCs, using 1 VPI 
and 12 VCIs. The VCC MUST be configured as either a CBR or VBR 
connection. The VPI/VCIs MUST not be one of the reserved ATM 
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5) 


signaling channels (e.g., [0,5], [0,16]). The PCR, SCR, and MBS 
must be configured using one of the specified traffic 
descriptors. 


Send a specific number of IP packets containing one of the 
specified bit patterns at a specific rate through the SUT via the 
defined test VCCs. All of the VPI/VCI pairs will generate 
traffic at the same traffic rate. Since this test is not a 
throughput test, the rate should not be greater than 90% of line 
rate. The PCR, SCR, and MBS must be indicated. The IP PDUs MUST 
be encapsulated in AAL5. 


Count the IP packets that are transmitted by the SUT on all VCCs 
to verify connectivity and load. If the count on the test device 
is the same on the SUT, continue the test; else lower the test 
device traffic rate until the counts are the same. 


Record the number of CRC errored cells received per VCC on the 
test device for all VCCs. 


Reporting Format: 


The results of the CRC-ER/Bursty VBR Load/Twelve VCCs test SHOULD 
be reported in a form of text and graph. 


The text results SHOULD display the numerical values of the CRC- 
ER. The values given SHOULD include: time period of test in s, 
test VPI/VCI value, total number of cells transmitted and received 
on the given VPI/VCI during the test in positive integers, and the 
CRC-ER for the entire test. 


The graph results SHOULD display the CRC Error ratio values. The 
x-coordinate SHOULD be the test run time in either seconds, 
minutes or days depending on the total length of the test. The 
x-coordinate time SHOULD be configurable. The y-coordinate SHOULD 
be the CRC-ER for each VCC. There should be 12 curves on the 
graph, on curve indicated and labeled for each VCC. The 
integration time per point MUST be indicated. 


The results MUST also indicate the packet size in octets, traffic 
rate in packets per second, and bearer class as generated by the 
test device. The VCC and VPI/VCI values MUST be indicated. The 
PCR, SCR, and MBS MUST be indicated. The bearer class of the 
created VCC MUST also be indicated. 
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3.2.5.6. CRC-ER/Bursty VBR Load/Maximum VCCs 


Objective: To determine the SUT ratio of lost cells with the maximum 
number VCCs supported on the SUT in a transmission in relation to the 
total cells sent as defined in RFC 2761 "Terminology for ATM 
Benchmarking". 


Procedure: 


1) 


5) 


Set up the SUT and test device using the bi-directional 
configuration. 


Configure the SUT and test device with the maximum number of VCCs 
supported on the SUT. For example, if the maximum number of VCCs 
supported on the SUT is 1024, define 256 VPIs with 4 VCIs per 
VPI. The VCC MUST be configured as either a CBR or VBR 
connection. The VPI/VCIs MUST not be one of the reserved ATM 
signaling channels (e.g., [0,5], [0,16]). The PCR, SCR, and MBS 
must be configured using one of the specified traffic 
descriptors. 


Send a specific number of IP packets containing one of the 
specified bit patterns at a specific rate through the SUT via the 
defined test VCCs. All of the VPI/VCI pairs will generate 
traffic at the same traffic rate. Since this test is not a 
throughput test, the rate should not be greater than 90% of line 
rate. The IP PDUs MUST be encapsulated in AALD5. 


Count the IP packets that are transmitted by the SUT on all VCCs 
to verify connectivity and load. If the count on the test device 
is the same on the SUT, continue the test; else lower the test 
device traffic rate until the counts are the same. 


Record the number of CRC errored cells received per VCC on the 
test device for all VCCs. 


Reporting Format: 


The results of the CRC-ER/Bursty VBR Load/Maximum VCCs test SHOULD 
be reported in a form of text and graph. 


The text results SHOULD display the numerical values of the CRC- 
ER. The values given SHOULD include: time period of test in s, 
test VPI/VCI value, total number of cells transmitted and received 
on the given VPI/VCI during the test in positive integers, and the 
CRC-ER for the entire test. 


The graph results SHOULD display the CRC Error ratio values. 


Dunn & Martin Informational [Page 68] 


RFC 3116 Methodology for ATM Benchmarking June 2001 


There will be (Max number of VCCs/10) graphs, with 10 VCCs 
indicated on each graph. The x-coordinate SHOULD be the test run 
time in either seconds, minutes or days depending on the total 
length of the test. The x-coordinate time SHOULD be configurable. 
The y-coordinate SHOULD be the CRC-ER for each VCC. There SHOULD 
be no more than 10 curves on each graph, one curve indicated and 
labeled for each VCC. The integration time per point MUST be 
indicated. 


The results MUST also indicate the packet size in octets, traffic 
rate in packets per second, and bearer class as generated by the 
test device. The VCC and VPI/VCI values MUST be indicated. The 
PCR, SCR, and MBS MUST be indicated. The bearer class of the 
created VCC MUST also be indicated. 


3.2.5.7. CRC-ER/Bursty UBR Load/One VCC 


Objective: To determine the SUT ratio of lost cells on one VCC ina 
transmission in relation to the total cells sent as defined in RFC 
2761 "Terminology for ATM Benchmarking". 


Procedure: 


1) 


Set up the SUT and test device using the bi-directional 
configuration. 


Configure the SUT and test device with one VCC. The VCC SHOULD 
contain one VPI/VCI. The VCC MUST be configured as a UBR 
connection. The VPI/VCI MUST not be one of the reserved ATM 
signaling channels (e.g., [0,5], [0,16]). The PCR, SCR, and MBS 
must be configured using one of the specified traffic 
descriptors. 


Send a specific number of IP packets containing one of the 
specified bit patterns at a specific rate through the SUT via the 
defined test VCC. Since this test is not a throughput test, the 
rate should not be greater than 90% of line rate. The IP PDUs 
MUST be encapsulated in AAL5. 


Count the IP packets that are transmitted by the SUT to verify 
connectivity and load. If the count on the test device is the 
same on the SUT, continue the test; else lower the test device 
traffic rate until the counts are the same. 


Record the number of CRC errored cells received per VCC on the 
test device. 
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Reporting Format: 


The results of the CRC-ER/Bursty UBR Load/One VCC test SHOULD be 
reported in a form of text and graph. 


The text results SHOULD display the numerical values of the CRC- 
ER. The values given SHOULD include: time period of test in s, 
test VPI/VCI value, total number of cells transmitted and received 
on the given VPI/VCI during the test in positive integers, and the 
CRC-ER for the entire test. 


The graph results SHOULD display the CRC Error ratio values. The 
x-coordinate SHOULD be the test run time in either seconds, 
minutes or days depending on the total length of the test. The 
x-coordinate time SHOULD be configurable. The y-coordinate SHOULD 
be the CRC-ER. The integration time per point MUST be indicated. 


The results MUST also indicate the packet size in octets, traffic 
rate in packets per second, and bearer class as generated by the 
test device. The VCC and VPI/VCI values MUST be indicated. The 
PCR, SCR, and MBS MUST be indicated. The bearer class of the 
created VCC MUST also be indicated. 


3.2.5.8. CRC-ER/Bursty UBR Load/Twelve VCCs 


Objective: To determine the SUT ratio of lost cells on twelve VCCs in 
a transmission in relation to the total cells sent as defined in RFC 
2761 "Terminology for ATM Benchmarking". 


Procedure: 


1) 


Set up the SUT and test device using the bi-directional 
configuration. 


Configure the SUT and test device with twelve VCCs, using 1 VPI 
and 12 VCIs. The VCC MUST be configured as a UBR connection. 
The VPI/VCIs MUST not be one of the reserved ATM signaling 
channels (e.g., [0,5], [0,16]). The PCR, SCR, and MBS must be 
configured using one of the specified traffic descriptors. 


Send a specific number of IP packets containing one of the 
specified bit patterns at a specific rate through the SUT via the 
defined test VCCs. All of the VPI/VCI pairs will generate 
traffic at the same traffic rate. Since this test is not a 
throughput test, the rate should not be greater than 90% of line 
rate. The PCR, SCR, and MBS must be indicated. The IP PDUs MUST 
be encapsulated in AALS. 
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4) 


5) 


Count the IP packets that are transmitted by the SUT on all VCCs 
to verify connectivity and load. If the count on the test device 
is the same on the SUT, continue the test; else lower the test 
device traffic rate until the counts are the same. 


Record the number of CRC errored cells received per VCC on the 
test device for all VCCs. 


Reporting Format: 


The results of the CRC-ER/Bursty UBR Load/Twelve VCCs test SHOULD 
be reported in a form of text and graph. 


The text results SHOULD display the numerical values of the CRC- 
ER. The values given SHOULD include: time period of test in s, 
test VPI/VCI value, total number of cells transmitted and received 
on the given VPI/VCI during the test in positive integers, and the 
CRC-ER for the entire test. 


The graph results SHOULD display the CRC Error ratio values. The 
x-coordinate SHOULD be the test run time in either seconds, 
minutes or days depending on the total length of the test. The 
x-coordinate time SHOULD be configurable. The y-coordinate SHOULD 
be the CRC-ER for each VCC. There should be 12 curves on the 
graph, on curve indicated and labeled for each VCC. The 
integration time per point MUST be indicated. 


The results MUST also indicate the packet size in octets, traffic 
rate in packets per second, and bearer class as generated by the 
test device. The VCC and VPI/VCI values MUST be indicated. The 
PCR, SCR, and MBS MUST be indicated. The bearer class of the 
created VCC MUST also be indicated. 


3.2.5.9. CRC-ER/Bursty UBR Load/Maximum VCCs 


Objective: To determine the SUT ratio of lost cells with the maximum 
number VCCs supported on the SUT in a transmission in relation to the 
total cells sent as defined in RFC 2761 "Terminology for ATM 
Benchmarking". 


Procedure: 


1) 


Set up the SUT and test device using the bi-directional 
configuration. 


Configure the SUT and test device with the maximum number of VCCs 
supported on the SUT. For example, if the maximum number of VCCs 
supported on the SUT is 1024, define 256 VPIs with 4 VCIs per 
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VPI. The VCC MUST be configured as a UBR connection. The 
VPI/VCIs MUST not be one of the reserved ATM signaling channels 
(e.g., [0,5], [0,16]). The PCR, SCR, and MBS must be configured 
using one of the specified traffic descriptors. 


3) Send a specific number of IP packets containing one of the 
specified bit patterns at a specific rate through the SUT via the 
defined test VCCs. All of the VPI/VCI pairs will generate 
traffic at the same traffic rate. Since this test is not a 
throughput test, the rate should not be greater than 90% of line 
rate. The IP PDUs MUST be encapsulated in AALD5. 


4) Count the IP packets that are transmitted by the SUT on all VCCs 
to verify connectivity and load. If the count on the test device 
is the same on the SUT, continue the test; else lower the test 
device traffic rate until the counts are the same. 


5) Record the number of CRC errored cells received per VCC on the 
test device for all VCCs. 


Reporting Format: 


The results of the CRC-ER/Bursty UBR Load/Maximum VCCs test SHOULD 
be reported in a form of text and graph. 


The text results SHOULD display the numerical values of the CRC- 
ER. The values given SHOULD include: time period of test in s, 
test VPI/VCI value, total number of cells transmitted and received 
on the given VPI/VCI during the test in positive integers, and the 
CRC-ER for the entire test. 


The graph results SHOULD display the CRC Error ratio values. 

There will be (Max number of VCCs/10) graphs, with 10 VCCs 
indicated on each graph. The x-coordinate SHOULD be the test run 
time in either seconds, minutes or days depending on the total 
length of the test. The x-coordinate time SHOULD be configurable. 
The y-coordinate SHOULD be the CRC-ER for each VCC. There SHOULD 
be no more than 10 curves on each graph, one curve indicated and 
labeled for each VCC. The integration time per point MUST be 
indicated. 


The results MUST also indicate the packet size in octets, traffic 
rate in packets per second, and bearer class as generated by the 
test device. The VCC and VPI/VCI values MUST be indicated. The 
PCR, SCR, and MBS MUST be indicated. The bearer class of the 
created VCC MUST also be indicated. 
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3.2.5.10. CRC-ER/Bursty Mixed Load/Three VCC 


Objective: To determine the SUT ratio of lost cells on three VCC’s in 
relation to the total cells sent as defined in RFC 2761 "Terminology 
for ATM Benchmarking". 


Procedure: 


1) 


5) 


Set up the SUT and test device using the bi-directional 
configuration. 


Configure the SUT and test device with three VCC’s. Each VCC 
MUST be defined as a different Bearer class; one CBR, one UBR and 
one VBR. Each VCC SHOULD contain one VPI/VCI. The VPI/VCI MUST 
not be one of the reserved ATM signaling channels (e.g., [0,5], 
[0,16]). The PCR, SCR, and MBS must be configured using one of 
the specified traffic descriptors. 


Send a specific number of IP packets containing one of the 
specified bit patterns through the SUT via the defined test VCCs. 
Each generated VCC stream MUST match the corresponding VCC Bearer 
class. All of the VPI/VCI pairs will generate traffic at the 
same traffic rate. Since this test is not a throughput test, the 
rate should not be greater than 90% of line rate. The IP PDUs 
MUST be encapsulated in AAL5. 


Count the IP packets that are transmitted by the SUT to verify 
connectivity and load. If the count on the test device is the 
same on the SUT, continue the test; else lower the test device 
traffic rate until the counts are the same. 


Record the number of CRC errored cells received per VCC on the 
test device. 


Reporting Format: 


The results of the CRC-ER/Bursty Mixed Load/Three VCC test SHOULD 
be reported in in a form of text and graph. 


The text results SHOULD display the numerical values of the CRC- 
ER. The values given SHOULD include: time period of test in s, 
test VPI/VCI value, total number of cells transmitted and received 
on the given VPI/VCI during the test in positive integers, and the 
CRC-ER for the entire test. 


The graph results SHOULD display the CRC Error ratio values. The 
x-coordinate SHOULD be the test run time in either seconds, 
minutes or days depending on the total length of the test. The 
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x-coordinate time SHOULD be configurable. The y-coordinate SHOULD 
be the CRC-ER for each VCC. There should be 12 curves on the 
graph, on curve indicated and labeled for each VCC. The 
integration time per point MUST be indicated. 


The results MUST also indicate the packet size in octets, traffic 
rate in packets per second, and bearer class as generated by the 
test device. The VCC and VPI/VCI values MUST be indicated. The 
PCR, SCR, and MBS MUST be indicated. The bearer class of the 
created VCC MUST also be indicated. 


3.2.5.11. CRC-ER/Bursty Mixed Load/Twelve VCCs 


Objective: To determine the SUT ratio of lost cells on twelve VCCs in 
a transmission in relation to the total cells sent as defined in RFC 
2761 "Terminology for ATM Benchmarking". 


Procedure: 


1) 


5) 


Set up the SUT and test device using the bi-directional 
configuration. 


Configure the SUT and test device with twelve VCC’s. Each VCC 
MUST be defined as one of the Bearer classes for a total of four 
CBR, four UBR and four VBR VCC’s. Each VCC SHOULD contain one 
VPI/VCI. The VPI/VCI MUST not be one of the reserved ATM 
signaling channels (e.g., [0,5], [0,16]). 


Send a specific number of IP packets containing one of the 
specified bit patterns through the SUT via the defined test VCCs. 
Each generated VCC stream MUST match the corresponding VCC Bearer 
class. All of the VPI/VCI pairs will generate traffic at the 
same traffic rate. Since this test is not a throughput test, the 
rate should not be greater than 90% of line rate. The IP PDUs 
MUST be encapsulated in AAL5. 


Count the IP packets that are transmitted by the SUT on all VCCs 
to verify connectivity and load. If the count on the test device 
is the same on the SUT, continue the test; else lower the test 
device traffic rate until the counts are the same. 


Record the number of CRC errored cells received per VCC on the 
test device for all VCCs. 


Reporting Format: 


The results of the CRC-ER/Bursty Mixed Load/Twelve VCCs test 
SHOULD be reported in a form of text and graph. 
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The text results SHOULD display the numerical values of the CRC- 
ER. The values given SHOULD include: time period of test in s, 
test VPI/VCI value, total number of cells transmitted and received 
on the given VPI/VCI during the test in positive integers, and the 
CRC-ER for the entire test. 


The graph results SHOULD display the CRC Error ratio values. The 
x-coordinate SHOULD be the test run time in either seconds, 
minutes or days depending on the total length of the test. The 
x-coordinate time SHOULD be configurable. The y-coordinate SHOULD 
be the CRC-ER for each VCC. There should be 12 curves on the 
graph, on curve indicated and labeled for each VCC. The 
integration time per point MUST be indicated. 


The results MUST also indicate the packet size in octets, traffic 
rate in packets per second, and bearer class as generated by the 
test device. The VCC and VPI/VCI values MUST be indicated. The 
PCR, SCR, and MBS MUST be indicated. The bearer class of the 
created VCC MUST also be indicated. 


3.2.5.12. CRC-ER/Bursty Mixed Load/Maximum VCCs 


Objective: To determine the SUT ratio of lost cells with the maximum 
number VCCs supported on the SUT in a transmission in relation to the 
total cells sent as defined in RFC 2761 "Terminology for ATM 
Benchmarking". 


Procedure: 


1) 


Set up the SUT and test device using the bi-directional 
configuration. 


Configure the SUT and test device with maximum number of VCCs 
supported on the SUT. For example, if the maximum number of VCCs 
supported on the SUT is 1024, define 256 VPIs with 4 VCIs per 
VPI. Each VCC MUST be defined as one of the Bearer classes for a 
total of (max VCC/3) CBR, (max VCC/3) UBR and (max VCC/3) VBR 
vcc’s. The VPI/VCI MUST not be one of the reserved ATM signaling 
channels (e.g., [0,5], [0,16]). 


Send a specific number of IP packets containing one of the 
specified bit patterns through the SUT via the defined test VCCs. 
Each generated VCC stream MUST match the corresponding VCC Bearer 
class. All of the VPI/VCI pairs will generate traffic at the 
same traffic rate. Since this test is not a throughput test, the 
rate should not be greater than 90% of line rate. The IP PDUs 
MUST be encapsulated in AAL5. 
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4) Count the IP packets that are transmitted by the SUT on all VCCs 
to verify connectivity and load. If the count on the test device 
is the same on the SUT, continue the test; else lower the test 
device traffic rate until the counts are the same. 


5) Record the number of CRC errored cells received per VCC on the 
test device for all VCCs. 


Reporting Format: 


The results of the CRC-ER/Bursty Mixed Load/Maximum VCCs test 
SHOULD be reported in a form of text and graph. 


The text results SHOULD display the numerical values of the CRC- 
ER. The values given SHOULD include: time period of test in s, 
test VPI/VCI value, total number of cells transmitted and received 
on the given VPI/VCI during the test in positive integers, and the 
CRC-ER for the entire test. 


The graph results SHOULD display the CRC Error ratio values. 

There will be (Max number of VCCs/10) graphs, with 10 VCCs 
indicated on each graph. The x-coordinate SHOULD be the test run 
time in either seconds, minutes or days depending on the total 
length of the test. The x-coordinate time SHOULD be configurable. 
The y-coordinate SHOULD be the CRC-ER for each VCC. There SHOULD 
be no more than 10 curves on each graph, one curve indicated and 
labeled for each VCC. The integration time per point MUST be 
indicated. 


The results MUST also indicate the packet size in octets, traffic 
rate in packets per second, and bearer class as generated by the 
test device. The VCC and VPI/VCI values MUST be indicated. The 
PCR, SCR, and MBS MUST be indicated. The bearer class of the 
created VCC MUST also be indicated. 


6. Cell Transfer Delay (CTD) 


3.2.6.1. Test Setup 


The cell transfer delay measurements assume that both the transmitter 
and receiver timestamp information is synchronized. Synchronization 
SHOULD be achieved by supplying a common clock signal (minimum of 100 
Mhz or 10 ns resolution) to both the transmitter and receiver. The 
maximum timestamp values MUST be recorded to ensure synchronization 
in the case of counter rollover. The cell transfer delay 
measurements SHOULD utilize the 0.191 cell (ITUT-0O.191) encapsulated 
in a valid IP packet. If the 0.191 cell is not available, a test 
cell encapsulated in a valid IP packet MAY be used. The test cell 
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MUST contain a transmit timestamp which can be correlated with a 
receive timestamp. A description of the test cell MUST be included 


in the test results. The description MUST include the timestamp 
length (in bits), counter rollover value, and the timestamp accuracy 
(in ns). 


3.2.6.2. CTD/Steady Load/One VCC 


Objective: To determine the SUT variation in cell transfer delay with 
one VCC as defined in RFC 2761 "Terminology for ATM Benchmarking". 


Procedure: 


1) Set up the SUT and test device using the bi-directional 
configuration. 


2) Configure the SUT and test device with one VCC. The VCC SHOULD 
contain one VPI/VCI. The VCC MUST be configured as either a CBR, 
VBR, or UBR connection. The VPI/VCI MUST not be one of the 
reserved ATM signaling channels (e.g., [0,5], [0,16]). 


3) Send a specific number of IP packets containing timestamps at a 
specific constant rate through the SUT via the defined test VCC. 
Since this test is not a throughput test, the rate should not be 
greater than 90% of line rate. The IP PDUs MUST be encapsulated 
in AALS. 


4) Count the IP packets that are transmitted by the SUT to verify 
connectivity and load. If the count on the test device is the 
same on the SUT, continue the test; else lower the test device 
traffic rate until the counts are the same. 


5) Record the packets timestamps at the transmitter and receiver 
ends of the test device. 


Reporting Format: 


The results of the CTD/Steady Load/One VCC test SHOULD be reported 
in a form of text, graph, and histogram. 


The text results SHOULD display the numerical values of the CTD. 
The values given SHOULD include: time period of test in s, test 

VPI/VCI value, total number of cells transmitted and received on 
the given VPI/VCI during the test in positive integers, minimum, 
maximum, and mean CTD during the test in us. 


The graph results SHOULD display the cell transfer delay values. 
The x-coordinate SHOULD be the test run time in either seconds, 
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minutes or days depending on the total length of the test. The 
x-coordinate time SHOULD be configurable. The y-coordinate SHOULD 
be the cell transfer delay in us. The integration time per point 
MUST be indicated. 


The histogram results SHOULD display the cell transfer delay. The 
x-coordinate SHOULD be the cell transfer delay in us with at least 
256 bins. The y-coordinate SHOULD be the number of cells observed 
in each bin. 


The results MUST also indicate the packet size in octets, traffic 
rate in packets per second, and bearer class as generated by the 
test device. The VCC and VPI/VCI values MUST be indicated. The 
bearer class of the created VCC MUST also be indicated. 


3.2.6.3. CTD/Steady Load/Twelve VCCs 


Objective: To determine the SUT variation in cell transfer delay with 
twelve VCCs as defined in RFC 2761 "Terminology for ATM 
Benchmarking". 


Procedure: 


1) 


Set up the SUT and test device using the bi-directional 
configuration. 


Configure the SUT and test device with twelve VCCs, using 1 VPI 

and 12 VCIs. The VCC’s MUST be configured as either a CBR, VBR, 
or UBR connection. The VPI/VCIs MUST not be one of the reserved 
ATM signaling channels (e.g., [0,5], [0,16]). 


Send a specific number of IP packets containing timestamps at a 
specific constant rate through the SUT via the defined test VCCs. 
All of the VPI/VCI pairs will generate traffic at the same 
traffic rate. Since this test is not a throughput test, the rate 
should not be greater than 90% of line rate. The IP PDUs MUST be 
encapsulated in AAL5. 


Count the IP packets that are transmitted by the SUT on all VCCs 
to verify connectivity and load. If the count on the test device 
is the same on the SUT, continue the test; else lower the test 
device traffic rate until the counts are the same. 


Record the packets timestamps at the transmitter and receiver 
ends of the test device for all VCCs. 
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Reporting Format: 


The results of the CTD/Steady Load/Twelve VCCs test SHOULD be 
reported in a form of text, graph, and histograms. 


The text results SHOULD display the numerical values of the CTD. 
The values given SHOULD include: time period of test in s, test 
VPI/VCI values, total number of cells transmitted and received on 
each VCC during the test in positive integers, maximum and minimum 
CTD on each VCC during the test in us, and mean CTD on each VCC in 
us. 


The graph results SHOULD display the cell transfer delay values. 
The x-coordinate SHOULD be the test run time in either seconds, 
minutes or days depending on the total length of the test. The 
x-coordinate time SHOULD be configurable. The y-coordinate SHOULD 
be the cell transfer delay for each VCC in ms. There SHOULD be 12 
curves on the graph, one curves indicated and labeled for each 
VCC. The integration time per point MUST be indicated. 


The histograms SHOULD display the cell transfer delay. There will 
be one histogram for each VCC. The x-coordinate SHOULD be the 
cell transfer delay in us with at least 256 bins. The y- 
coordinate SHOULD be the number of cells observed in each bin. 


The results MUST also indicate the packet size in octets, traffic 
rate in packets per second, and bearer class as generated by the 
test device. The VCC and VPI/VCI values MUST be indicated. The 
bearer class of the created VCC MUST also be indicated. 


3.2.6.4. CTD/Steady Load/Maximum VCCs 


Objective: To determine the SUT variation in cell transfer delay with 
the maximum number VCCs supported on the SUT as defined in RFC 2761 
"Terminology for ATM Benchmarking". 


Procedure: 


1) 


Set up the SUT and test device using the bi-directional 
configuration. 


Configure the SUT and test device with the maximum number of VCCs 
supported on the SUT. For example, if the maximum number of VCCs 
supported on the SUT is 1024, define 256 VPIs with 4 VCIs per 
VPI. The VCC’s MUST be configured as either a CBR, VBR, or UBR 
connection. The VPI/VCIs MUST not be one of the reserved ATM 
signaling channels (e.g., [0,5], [0,16]). 
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3) 


5) 


Send a specific number of IP packets containing timestamps at a 
specific constant rate through the SUT via the defined test VCCs. 
All of the VPI/VCI pairs will generate traffic at the same 
traffic rate. Since this test is not a throughput test, the rate 
should not be greater than 90% of line rate. The IP PDUs MUST be 
encapsulated in AAL5. 


Count the IP packets that are transmitted by the SUT on all VCCs 
to verify connectivity and load. If the count on the test device 
is the same on the SUT, continue the test; else lower the test 
device traffic rate until the counts are the same. 


Record the packets timestamps at the transmitter and receiver 
ends of the test device for all VCCs. 


Reporting Format: 


The results of the CTD/Steady Load/Maximum VCCs test SHOULD be 
reported in a form of text, graphs, and histograms. 


The text results SHOULD display the numerical values of the CTD. 
The values given SHOULD include: time period of test in s, test 
VPI/VCI values, total number of cells transmitted and received on 
each VCC during the test in positive integers, maximum and minimum 
CTD on each VCC during the test in us, and mean CTD on each VCC in 
us. 


The graph results SHOULD display the cell transfer delay values. 
There will be (Max number of VCCs/10) graphs, with 10 VCCs 
indicated on each graph. The x-coordinate SHOULD be the test run 
time in either seconds, minutes or days depending on the total 
length of the test. The x-coordinate time SHOULD be configurable. 
The y-coordinate SHOULD be the cell transfer delay for each VCC in 
us. There SHOULD be no more than 10 curves on each graph, one 
curve indicated and labeled for each VCC. The integration time 
per point MUST be indicated. 


The histograms SHOULD display the cell transfer delay. There will 
be one histogram for each VCC. The x-coordinate SHOULD be the 
cell transfer delay in us with at least 256 bins. The y- 
coordinate SHOULD be the number of cells observed in each bin. 


The results MUST also indicate the packet size in octets, traffic 
rate in packets per second, and bearer class as generated by the 
test device. The VCC and VPI/VCI values MUST be indicated. The 
bearer class of the created VCC MUST also be indicated. 
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3.2.6.5. CTD/Bursty VBR Load/One VCC 


Objective: To determine the SUT variation in cell transfer delay with 
one VCC as defined in RFC 2761 "Terminology for ATM Benchmarking". 


Procedure: 


1) 


5) 


Set up the SUT and test device using the bi-directional 
configuration. 


Configure the SUT and test device with one VCC. The VCC SHOULD 
contain one VPI/VCI. The VCC MUST be configured as either a CBR 
or VBR connection. The VPI/VCI MUST not be one of the reserved 
ATM signaling channels (e.g., [0,5], [0,16]). 


Send a specific number of IP packets containing timestamps at a 
specific VBR through the SUT via the defined test VCC. Since 
this test is not a throughput test, the rate should not be 
greater than 90% of line rate. The IP PDUs MUST be encapsulated 
in AALS. 


Count the IP packets that are transmitted by the SUT to verify 
connectivity and load. If the count on the test device is the 
same on the SUT, continue the test; else lower the test device 
traffic rate until the counts are the same. 


Record the packets timestamps at the transmitter and receiver 
ends of the test device. 


Reporting Format: 


The results of the CTD/Bursty VBR Load/One VCC test SHOULD be 
reported in a form of text, graph, and histogram. 


The text results SHOULD display the numerical values of the CTD. 
The values given SHOULD include: time period of test in s, test 

VPI/VCI value, total number of cells transmitted and received on 
the given VPI/VCI during the test in positive integers, minimum, 
maximum, and mean CTD during the test in us. 


The graph results SHOULD display the cell transfer delay values. 
The x-coordinate SHOULD be the test run time in either seconds, 
minutes or days depending on the total length of the test. The 
x-coordinate time SHOULD be configurable. The y-coordinate SHOULD 
be the cell transfer delay in us. The integration time per point 
MUST be indicated. 
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The histogram results SHOULD display the cell transfer delay. The 
x-coordinate SHOULD be the cell transfer delay in us with at least 
256 bins. The y-coordinate SHOULD be the number of cells observed 
in each bin. 


The results MUST also indicate the packet size in octets, traffic 
rate in packets per second, and bearer class as generated by the 
test device. The VCC and VPI/VCI values MUST be indicated. The 
PCR, SCR, and MBS MUST be indicated. The bearer class of the 
created VCC MUST also be indicated. 


3.2.6.6. CTD/Bursty VBR Load/Twelve VCCs 


Objective: To determine the SUT variation in cell transfer delay with 
twelve VCCs as defined in RFC 2761 "Terminology for ATM 
Benchmarking". 


Procedure: 


1) 


5) 


Set up the SUT and test device using the bi-directional 
configuration. 


Configure the SUT and test device with twelve VCCs, using 1 VPI 
and 12 VCIs. The VCC’s MUST be configured as either a CBR or VBR 
connection. The VPI/VCIs MUST not be one of the reserved ATM 
signaling channels (e.g., [0,5], [0,16]). 


Send a specific number of IP packets containing timestamps at a 
specific VBR through the SUT via the defined test VCCs. All of 
the VPI/VCI pairs will generate traffic at the same traffic rate. 
Since this test is not a throughput test, the rate should not be 
greater than 90% of line rate. The IP PDUs MUST be encapsulated 
in AALS. 


Count the IP packets that are transmitted by the SUT on all VCCs 
to verify connectivity and load. If the count on the test device 
is the same on the SUT, continue the test; else lower the test 
device traffic rate until the counts are the same. 


Record the packets timestamps at the transmitter and receiver 
ends of the test device for all VCCs. 


Reporting Format: 


The results of the CTD/Bursty VBR Load/Twelve VCCs test SHOULD be 
reported in a form of text, graph, and histograms. 
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The text results SHOULD display the numerical values of the CTD. 
The values given SHOULD include: time period of test in s, test 
VPI/VCI values, total number of cells transmitted and received on 
each VCC during the test in positive integers, maximum and minimum 
CTD on each VCC during the test in us, and mean CTD on each VCC in 
us. 


The graph results SHOULD display the cell transfer delay values. 
The x-coordinate SHOULD be the test run time in either seconds, 
minutes or days depending on the total length of the test. The 
x-coordinate time SHOULD be configurable. The y-coordinate SHOULD 
be the cell transfer delay for each VCC in ms. There SHOULD be 12 
curves on the graph, one curves indicated and labeled for each 
VCC. The integration time per point MUST be indicated. 


The histograms SHOULD display the cell transfer delay. There will 
be one histogram for each VCC. The x-coordinate SHOULD be the 
cell transfer delay in us with at least 256 bins. The y- 
coordinate SHOULD be the number of cells observed in each bin. 


The results MUST also indicate the packet size in octets, traffic 
rate in packets per second, and bearer class as generated by the 
test device. The VCC and VPI/VCI values MUST be indicated. The 
PCR, SCR, and MBS MUST be indicated. The bearer class of the 
created VCC MUST also be indicated. 


3.2.6.7. CTD/Bursty VBR Load/Maximum VCCs 


Objective: To determine the SUT variation in cell transfer delay with 
the maximum number VCCs supported on the SUT as defined in RFC 2761 
"Terminology for ATM Benchmarking". 


Procedure: 


1) 


Set up the SUT and test device using the bi-directional 
configuration. 


Configure the SUT and test device with the maximum number of VCCs 
supported on the SUT. For example, if the maximum number of VCCs 
supported on the SUT is 1024, define 256 VPIs with 4 VCIs per 
VPI. The VCC’s MUST be configured as either a CBR or VBR 
connection. The VPI/VCIs MUST not be one of the reserved ATM 
signaling channels (e.g., [0,5], [0,16]). 


Send a specific number of IP packets containing timestamps at a 
specific VBR through the SUT via the defined test VCCs. All of 
the VPI/VCI pairs will generate traffic at the same traffic rate. 
Since this test is not a throughput test, the rate should not be 
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5) 


greater than 90% of line rate. The IP PDUs MUST be encapsulated 
in AALS. 


Count the IP packets that are transmitted by the SUT on all VCCs 
to verify connectivity and load. If the count on the test device 
is the same on the SUT, continue the test; else lower the test 
device traffic rate until the counts are the same. 


Record the packets timestamps at the transmitter and receiver 
ends of the test device for all VCCs. 


Reporting Format: 


The results of the CTD/Bursty VBR Load/Maximum VCCs test SHOULD be 
reported in a form of text, graphs, and histograms. 


The text results SHOULD display the numerical values of the CTD. 
The values given SHOULD include: time period of test in s, test 
VPI/VCI values, total number of cells transmitted and received on 
each VCC during the test in positive integers, maximum and minimum 
CTD on each VCC during the test in us, and mean CTD on each VCC in 
us. 


The graph results SHOULD display the cell transfer delay values. 
There will be (Max number of VCCs/10) graphs, with 10 VCCs 
indicated on each graph. The x-coordinate SHOULD be the test run 
time in either seconds, minutes or days depending on the total 
length of the test. The x-coordinate time SHOULD be configurable. 
The y-coordinate SHOULD be the cell transfer delay for each VCC in 
us. There SHOULD be no more than 10 curves on each graph, one 
curve indicated and labeled for each VCC. The integration time 
per point MUST be indicated. 


The histograms SHOULD display the cell transfer delay. There will 
be one histogram for each VCC. The x-coordinate SHOULD be the 
cell transfer delay in us with at least 256 bins. The y- 
coordinate SHOULD be the number of cells observed in each bin. 


The results MUST also indicate the packet size in octets, traffic 
rate in packets per second, and bearer class as generated by the 
test device. The VCC and VPI/VCI values MUST be indicated. The 
PCR, SCR, and MBS MUST be indicated. The bearer class of the 
created VCC MUST also be indicated. 
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3.2.6.8. CTD/Bursty UBR Load/One VCC 


Objective: To determine the SUT variation in cell transfer delay with 
one VCC as defined in RFC 2761 "Terminology for ATM Benchmarking". 


Procedure: 


1) 


5) 


Set up the SUT and test device using the bi-directional 
configuration. 


Configure the SUT and test device with one VCC. The VCC SHOULD 
contain one VPI/VCI. The VCC MUST be configured as a UBR 
connection. The VPI/VCI MUST not be one of the reserved ATM 
signaling channels (e.g., [0,5], [0,16]). 


Send a specific number of IP packets containing timestamps at a 
specific UBR through the SUT via the defined test VCC. Since 
this test is not a throughput test, the rate should not be 
greater than 90% of line rate. The IP PDUs MUST be encapsulated 
in AALS. 


Count the IP packets that are transmitted by the SUT to verify 
connectivity and load. If the count on the test device is the 
same on the SUT, continue the test; else lower the test device 
traffic rate until the counts are the same. 


Record the packets timestamps at the transmitter and receiver 
ends of the test device. 


Reporting Format: 


The results of the CTD/Bursty UBR Load/One VCC test SHOULD be 
reported in a form of text, graph, and histogram. 


The text results SHOULD display the numerical values of the CTD. 
The values given SHOULD include: time period of test in s, test 

VPI/VCI value, total number of cells transmitted and received on 
the given VPI/VCI during the test in positive integers, minimum, 
maximum, and mean CTD during the test in us. 


The graph results SHOULD display the cell transfer delay values. 
The x-coordinate SHOULD be the test run time in either seconds, 
minutes or days depending on the total length of the test. The 
x-coordinate time SHOULD be configurable. The y-coordinate SHOULD 
be the cell transfer delay in us. The integration time per point 
MUST be indicated. 
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The histogram results SHOULD display the cell transfer delay. The 
x-coordinate SHOULD be the cell transfer delay in us with at least 
256 bins. The y-coordinate SHOULD be the number of cells observed 
in each bin. 


The results MUST also indicate the packet size in octets, traffic 
rate in packets per second, and bearer class as generated by the 
test device. The VCC and VPI/VCI values MUST be indicated. The 
bearer class of the created VCC MUST also be indicated. 


3.2.6.9. CTD/Bursty UBR Load/Twelve VCCs 


Objective: To determine the SUT variation in cell transfer delay with 
twelve VCCs as defined in RFC 2761 "Terminology for ATM 
Benchmarking". 


Procedure: 


1) 


5) 


Set up the SUT and test device using the bi-directional 
configuration. 


Configure the SUT and test device with twelve VCCs, using 1 VPI 
and 12 VCIs. The VCC’s MUST be configured as a UBR connection. 
The VPI/VCIs MUST not be one of the reserved ATM signaling 
channels (e.g., [0,5], [0,16]). 


Send a specific number of IP packets containing timestamps at a 
specific UBR through the SUT via the defined test VCCs. All of 
the VPI/VCI pairs will generate traffic at the same traffic rate. 
Since this test is not a throughput test, the rate should not be 
greater than 90% of line rate. The IP PDUs MUST be encapsulated 
in AALS. 


Count the IP packets that are transmitted by the SUT on all VCCs 
to verify connectivity and load. If the count on the test device 
is the same on the SUT, continue the test; else lower the test 
device traffic rate until the counts are the same. 


Record the packets timestamps at the transmitter and receiver 
ends of the test device for all VCCs. 


Reporting Format: 


The results of the CTD/Bursty UBR Load/Twelve VCCs test SHOULD be 
reported in a form of text, graph, and histograms. 


The text results SHOULD display the numerical values of the CTD. 
The values given SHOULD include: time period of test in s, test 
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VPI/VCI values, total number of cells transmitted and received on 
each VCC during the test in positive integers, maximum and minimum 
CTD on each VCC during the test in us, and mean CTD on each VCC in 
us. 


The graph results SHOULD display the cell transfer delay values. 
The x-coordinate SHOULD be the test run time in either seconds, 
minutes or days depending on the total length of the test. The 
x-coordinate time SHOULD be configurable. The y-coordinate SHOULD 
be the cell transfer delay for each VCC in ms. There SHOULD be 12 
curves on the graph, one curves indicated and labeled for each 
VCC. The integration time per point MUST be indicated. 


The histograms SHOULD display the cell transfer delay. There will 
be one histogram for each VCC. The x-coordinate SHOULD be the 
cell transfer delay in us with at least 256 bins. The y- 
coordinate SHOULD be the number of cells observed in each bin. 


The results MUST also indicate the packet size in octets, traffic 
rate in packets per second, and bearer class as generated by the 
test device. The VCC and VPI/VCI values MUST be indicated. The 
bearer class of the created VCC MUST also be indicated. 


3.2.6.10. CTD/Bursty UBR Load/Maximum VCCs 


Objective: To determine the SUT variation in cell transfer delay with 
the maximum number VCCs supported on the SUT as defined in RFC 2761 
"Terminology for ATM Benchmarking". 


Procedure: 


1) 


Set up the SUT and test device using the bi-directional 
configuration. 


Configure the SUT and test device with the maximum number of VCCs 
supported on the SUT. For example, if the maximum number of VCCs 
supported on the SUT is 1024, define 256 VPIs with 4 VCIs per 
VPI. The VCC MUST be configured as a UBR connection. The 
VPI/VCIs MUST not be one of the reserved ATM signaling channels 
(e.g., [0,5], [0,16]). 


Send a specific number of IP packets containing timestamps at a 
specific UBR through the SUT via the defined test VCCs. All of 
the VPI/VCI pairs will generate traffic at the same traffic rate. 
Since this test is not a throughput test, the rate should not be 
greater than 90% of line rate. The IP PDUs MUST be encapsulated 
in AALS. 
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4) 


5) 


Count the IP packets that are transmitted by the SUT on all VCCs 
to verify connectivity and load. If the count on the test device 
is the same on the SUT, continue the test; else lower the test 
device traffic rate until the counts are the same. 


Record the packets timestamps at the transmitter and receiver 
ends of the test device for all VCCs. 


Reporting Format: 


The results of the CTD/Bursty UBR Load/Maximum VCCs test SHOULD be 
reported in a form of text, graphs, and histograms. 


The text results SHOULD display the numerical values of the CTD. 
The values given SHOULD include: time period of test in s, test 
VPI/VCI values, total number of cells transmitted and received on 
each VCC during the test in positive integers, maximum and minimum 
CTD on each VCC during the test in us, and mean CTD on each VCC in 
us. 


The graph results SHOULD display the cell transfer delay values. 
There will be (Max number of VCCs/10) graphs, with 10 VCCs 
indicated on each graph. The x-coordinate SHOULD be the test run 
time in either seconds, minutes or days depending on the total 
length of the test. The x-coordinate time SHOULD be configurable. 
The y-coordinate SHOULD be the cell transfer delay for each VCC in 
us. There SHOULD be no more than 10 curves on each graph, one 
curve indicated and labeled for each VCC. The integration time 
per point MUST be indicated. 


The histograms SHOULD display the cell transfer delay. There will 
be one histogram for each VCC. The x-coordinate SHOULD be the 
cell transfer delay in us with at least 256 bins. The y- 
coordinate SHOULD be the number of cells observed in each bin. 


The results MUST also indicate the packet size in octets, traffic 
rate in packets per second, and bearer class as generated by the 
test device. The VCC and VPI/VCI values MUST be indicated. The 
bearer class of the created VCC MUST also be indicated. 


3.2.6.11. CTD/Mixed Load/Three VCC’s 


Objective: To determine the SUT variation in cell transfer delay with 
three VCC’s as defined in RFC 2761 "Terminology for ATM 
Benchmarking". 
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Procedure: 


1) 


5) 


Set up the SUT and test device using the bi-directional 
configuration. 


Configure the SUT and test device with three VCC’s. Each VCC 
MUST be defined as a different Bearer class: one CBR, one UBR and 
one VBR. Each VCC SHOULD contain one VPI/VCI. The VPI/VCI MUST 
not be one of the reserved ATM signaling channels (e.g., [0,5], 
[0,16]). 


Send a specific number of IP packets containing timestamps 
through the SUT via the defined test VCCs. Each generated VCC 
stream MUST match the corresponding VCC Bearer class. All of the 
VPI/VCI pairs will generate traffic at the same traffic rate. 
Since this test is not a throughput test, the rate should not be 
greater than 90% of line rate. The IP PDUs MUST be encapsulated 
in AALS. 


Count the IP packets that are transmitted by the SUT to verify 
connectivity and load. If the count on the test device is the 
same on the SUT, continue the test; else lower the test device 
traffic rate until the counts are the same. 


Record the packets timestamps at the transmitter and receiver 
ends of the test device for all VCC’s. 


Reporting Format: 


The results of the CTD/Mixed Load/Three VCC test SHOULD be 
reported in a form of text, graph, and histogram. 


The text results SHOULD display the numerical values of the CTD. 
The values given SHOULD include: time period of test in s, test 

VPI/VCI value, total number of cells transmitted and received on 
the given VPI/VCI during the test in positive integers, minimum, 
maximum, and mean CTD during the test in us. 


The graph results SHOULD display the cell transfer delay values. 
The x-coordinate SHOULD be the test run time in either seconds, 
minutes or days depending on the total length of the test. The 
x-coordinate time SHOULD be configurable. The y-coordinate SHOULD 
be the cell transfer delay in us. The integration time per point 
MUST be indicated. 
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The histogram results SHOULD display the cell transfer delay. The 
x-coordinate SHOULD be the cell transfer delay in us with at least 
256 bins. The y-coordinate SHOULD be the number of cells observed 
in each bin. 


The results MUST also indicate the packet size in octets, traffic 
rate in packets per second, and bearer class as generated by the 
test device. The VCC and VPI/VCI values MUST be indicated. The 
PCR, SCR, and MBS MUST be indicated. The bearer class of the 
created VCC MUST also be indicated. 


3.2.6.12. CTD/Mixed Load/Twelve VCCs 


Objective: To determine the SUT variation in cell transfer delay with 
twelve VCCs as defined in RFC 2761 "Terminology for ATM 
Benchmarking". 


Procedure: 


1) 


5) 


Set up the SUT and test device using the bi-directional 
configuration. 


Configure the SUT and test device with twelve VCC’s. Each VCC 
MUST be defined as one of the Bearer classes for a total of four 
CBR, four UBR and four VBR VCC’s. Each VCC SHOULD contain one 
VPI/VCI. The VPI/VCI MUST not be one of the reserved ATM 
signaling channels (e.g., [0,5], [0,16]). 


Send a specific number of IP packets containing timestamps 
through the SUT via the defined test VCCs. Each generated VCC 
stream MUST match the corresponding VCC Bearer class. All of the 
VPI/VCI pairs will generate traffic at the same traffic rate. 
Since this test is not a throughput test, the rate should not be 
greater than 90% of line rate. The IP PDUs MUST be encapsulated 
in AALS. 


Count the IP packets that are transmitted by the SUT on all VCCs 
to verify connectivity and load. If the count on the test device 
is the same on the SUT, continue the test; else lower the test 
device traffic rate until the counts are the same. 


Record the packets timestamps at the transmitter and receiver 
ends of the test device for all VCCs. 


Reporting Format: 


The results of the CTD/Mixed Load/Twelve VCCs test SHOULD be 
reported in a form of text, graph, and histograms. 
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The text results SHOULD display the numerical values of the CTD. 
The values given SHOULD include: time period of test in s, test 
VPI/VCI values, total number of cells transmitted and received on 
each VCC during the test in positive integers, maximum and minimum 
CTD on each VCC during the test in us, and mean CTD on each VCC in 
us. 


The graph results SHOULD display the cell transfer delay values. 
The x-coordinate SHOULD be the test run time in either seconds, 
minutes or days depending on the total length of the test. The 
x-coordinate time SHOULD be configurable. The y-coordinate SHOULD 
be the cell transfer delay for each VCC in ms. There SHOULD be 12 
curves on the graph, one curves indicated and labeled for each 
VCC. The integration time per point MUST be indicated. 


The histograms SHOULD display the cell transfer delay. There will 
be one histogram for each VCC. The x-coordinate SHOULD be the 
cell transfer delay in us with at least 256 bins. The y- 
coordinate SHOULD be the number of cells observed in each bin. 


The results MUST also indicate the packet size in octets, traffic 
rate in packets per second, and bearer class as generated by the 
test device. The VCC and VPI/VCI values MUST be indicated. The 
PCR, SCR, and MBS MUST be indicated. The bearer class of the 
created VCC MUST also be indicated. 


3.2.6.13. CTD/Mixed Load/Maximum VCCs 


Objective: To determine the SUT variation in cell transfer delay with 
the maximum number VCCs supported on the SUT as defined in RFC 2761 
"Terminology for ATM Benchmarking". 


Procedure: 


1) 


Set up the SUT and test device using the bi-directional 
configuration. 


Configure the SUT and test device with maximum number of VCCs 
supported on the SUT. For example, if the maximum number of VCCs 
supported on the SUT is 1024, define 256 VPIs with 4 VCIs per 
VPI. Each VCC MUST be defined as one of the Bearer classes for a 
total of (max VCC/3) CBR, (max VCC/3) UBR and (max VCC/3) VBR 
vec’s. If the maximum number of VCC’s is not divisible by 3, the 
total for each bearer class MUST be within 3 VCC’s of each other. 
The VPI/VCI MUST not be one of the reserved ATM signaling 
channels (e.g., [0,5], [0,16]). 
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3) 


5) 


Send a specific number of IP packets containing timestamps 
through the SUT via the defined test VCCs. Each generated VCC 
stream MUST match the corresponding VCC Bearer class. All of the 
VPI/VCI pairs will generate traffic at the same traffic rate. 
Since this test is not a throughput test, the rate should not be 
greater than 90% of line rate. The IP PDUs MUST be encapsulated 
in AALS. 


Count the IP packets that are transmitted by the SUT on all VCCs 
to verify connectivity and load. If the count on the test device 
is the same on the SUT, continue the test; else lower the test 
device traffic rate until the counts are the same. 


Record the packets timestamps at the transmitter and receiver 
ends of the test device for all VCCs. 


Reporting Format: 


The results of the CTD/Mixed Load/Maximum VCCs test SHOULD be 
reported in a form of text, graphs, and histograms. 


The text results SHOULD display the numerical values of the CTD. 
The values given SHOULD include: time period of test in s, test 
VPI/VCI values, total number of cells transmitted and received on 
each VCC during the test in positive integers, maximum and minimum 
CTD on each VCC during the test in us, and mean CTD on each VCC in 
us. 


The graph results SHOULD display the cell transfer delay values. 
There will be (Max number of VCCs/10) graphs, with 10 VCCs 
indicated on each graph. The x-coordinate SHOULD be the test run 
time in either seconds, minutes or days depending on the total 
length of the test. The x-coordinate time SHOULD be configurable. 
The y-coordinate SHOULD be the cell transfer delay for each VCC in 
us. There SHOULD be no more than 10 curves on each graph, one 
curve indicated and labeled for each VCC. The integration time 
per point MUST be indicated. 


The histograms SHOULD display the cell transfer delay. There will 
be one histogram for each VCC. The x-coordinate SHOULD be the 
cell transfer delay in us with at least 256 bins. The y- 
coordinate SHOULD be the number of cells observed in each bin. 


The results MUST also indicate the packet size in octets, traffic 
rate in packets per second, and bearer class as generated by the 
test device. The VCC and VPI/VCI values MUST be indicated. The 
PCR, SCR, and MBS MUST be indicated. The bearer class of the 
created VCC MUST also be indicated. 
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Bis 3 


Sie dele 


ATM Adaptation Layer (AAL) Type 5 (AAL5) 


IP Packet Loss due to AAL5 Re-assembly Errors 


Objective: To determine if the SUT will drop IP packets due AAL5 Re- 
assembly Errors as defined in RFC 2761 "Terminology for ATM 
Benchmarking". 


Procedure: 


1) 


7) 


Set up the SUT and test device using the uni-directional 
configuration. 


Send a specific number of cells at a specific rate through the 
SUT. Since this test is not a throughput test, the rate should 
not be greater than 90% of line rate. The cell payload SHOULD 
contain valid IP PDUs. The IP PDUs MUST be encapsulated in AAL5. 


Count the cells that are transmitted by the SUT to verify 
connectivity and load. If the count on the test device is the 
same on the SUT, continue the test; else lower the test device 
traffic rate until the counts are the same. 


Inject one error in the first bit of the AAL5 payload. Verify 
that the SUT does not drop any AAL5 PDU’s. 


Discontinue the AAL5 payload error. 

Inject one error in the first bit of the AAL5 header for 4 
consecutive IP PDUs in every 6 IP PDUs. Verify that the SUT does 
drop the AAL5 PDU’s. 


Discontinue the AAL5 payload error. 


Reporting Format: 


The results of the AAL5 PDU Loss due to AAL5 PDU errors test 
SHOULD be reported in a form of a table. The rows SHOULD be 
labeled single error, one error per second, and four consecutive 
errors every 6 IP PDUs. The columns SHOULD be labeled AAL5 PDU 
loss and number of PDU’s lost. The elements of column 1 SHOULD be 
either True or False, indicating whether the particular condition 
was observed for each test. The elements of column 2 SHOULD be 
non-negative integers. 


The table MUST also indicate the traffic rate in IP PDUs per 
second as generated by the test device. 
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B36 2% 


AAL5 Reassembly Time. 


Objective: To determine the SUT AAL5 Reassembly Time as defined in 
RFC 2761 "Terminology for ATM Benchmarking". 


Procedure: 


1) 


5) 


Set up the SUT and test device using the uni-directional 
configuration. 


Send a specific number of IP packets at a specific rate through 
the SUT. Since this test is not a throughput test, the rate 
should not be greater than 90% of line rate. The IP PDUs MUST be 
encapsulated in AAL5. The AAL5 PDU size is 65535 octets or 1365 
ATM cells. 


Count the IP packets that are transmitted by the SUT to verify 
connectivity and load. If the count on the test device is the 
same on the SUT, continue the test; else lower the test device 
traffic rate until the counts are the same. 


Given an AAL5 reassembly timer of ’x’ seconds, where ’x’ is the 
actual value of the AAL5 reassembly timer on the SUT, sent 
traffic at 1365 cells per ’x’ seconds. The expected results are 
that no AAL5 PDU’s will be dropped. 


Send traffic at 1360 cells per ’x’ seconds. The expected results 
are that all AAL5 PDU’s will be dropped. 


Reporting Format: 


The results of the IP packet loss due to AAL5 reassembly timeout 
test SHOULD be reported in a form of a table. The rows SHOULD be 
labeled 1365 cells per ’x’ seconds and 1360 cells per ’x’ seconds. 
The columns SHOULD be labeled packet loss and number of packets 


lost. The elements of column 1 SHOULD be either True or False, 
indicating whether the particular condition was observed for each 
test. The elements of column 2 SHOULD be non-negative integers. 


The table MUST also indicate the packet size in octets and traffic 
rate in packets per second as generated by the test device, 
including the value of 
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3.3.3. AAL5 CRC Error Ratio. 
3.3.3.1. Test Setup 


The AAL5 CRC error ratio measurements assume that both the 
transmitter and receiver payload information is synchronized. 
Synchronization MUST be achieved by supplying a known bit pattern to 
both the transmitter and receiver. If this bit pattern is longer 
than the packet size, the receiver MUST synchronize with the 
transmitter before tests can be run. 


3.3.3.2. AAL5-CRC-ER/Steady Load/One VCC 


Objective: To determine the SUT ratio of AAL5 CRC PDU errors on one 
VCC in a transmission in relation to the total AAL5 PDU’s sent as 
defined in RFC 2761 "Terminology for ATM Benchmarking". 


Procedure: 


1) Set up the SUT and test device using the bi-directional 
configuration. 


2) Configure the SUT and test device with one VCC. The VCC SHOULD 
contain one VPI/VCI. The VCC MUST be configured as either a CBR, 
VBR, or UBR connection. The VPI/VCI MUST not be one of the 
reserved ATM signaling channels (e.g., [0,5], [0,16]). 


3) Send a specific number of IP packets containing one of the 
specified bit patterns at a constant rate through the SUT via the 
defined test VCC. Since this test is not a throughput test, the 
rate should not be greater than 90% of line rate. The IP PDUs 
MUST be encapsulated in AAL5. 


4) Count the IP packets that are transmitted by the SUT to verify 
connectivity and load. If the count on the test device is the 
same on the SUT, continue the test; else lower the test device 
traffic rate until the counts are the same. 


5) Record the number of AAL5 CRC errors at the receiver end of the 
test device. 


Reporting Format: 


The results of the AAL5-CRC-ER/Steady Load/One VCC test SHOULD be 
reported in a form of text and graph. 
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The text results SHOULD display the numerical values of the AAL5-— 
CRC-ER. The values given SHOULD include: time period of test in 
s, test VPI/VCI value, total number of AAL5 PDU’s transmitted and 
received on the given VPI/VCI during the test in positive 
integers, and the AAL5-CRC-ER for the entire test. 


The graph results SHOULD display the AAL5 CRC error ratio values. 
The x-coordinate SHOULD be the test run time in either seconds, 
minutes or days depending on the total length of the test. The 
x-coordinate time SHOULD be configurable. The y-coordinate SHOULD 
be the AAL5-CRC-ER. The integration time per point MUST be 
indicated. 


The results MUST also indicate the packet size in octets, traffic 
rate in packets per second, and bearer class as generated by the 
test device. The VCC and VPI/VCI values MUST be indicated. The 
PCR, SCR, and MBS MUST be indicated. The bearer class of the 
created VCC MUST be indicated. The generated bit pattern MUST 
also be indicated. 


3.3.3.3. AAL5-CRC-ER/Steady Load/Twelve VCCs 


Objective: To determine the SUT ratio of AAL5 CRC PDU errors on 
twelve VCC’s in a transmission in relation to the total AAL5 PDU’s 
sent as defined in RFC 2761 "Terminology for ATM Benchmarking". 


Procedure: 


1) 


Set up the SUT and test device using the bi-directional 
configuration. 


Configure the SUT and test device with twelve VCCs, using 1 VPI 

and 12 VCIs. The VCC’s MUST be configured as either a CBR, VBR, 
or UBR connection. The VPI/VCIs MUST not be one of the reserved 
ATM signaling channels (e.g., [0,5], [0,16]). 


Send a specific number of IP packets containing one of the 
specified bit patterns at a constant rate through the SUT via the 
defined test VCCs. All of the VPI/VCI pairs will generate 
traffic at the same traffic rate. 


Since this test is not a throughput test, the rate should not be 
greater than 90% of line rate. The IP PDUs MUST be encapsulated 
in AALS. 
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4) 


5) 


Count the IP packets that are transmitted by the SUT on all VCCs 
to verify connectivity and load. If the count on the test device 
is the same on the SUT, continue the test; else lower the test 
device traffic rate until the counts are the same. 


Record the number of AAL5 CRC errors at the receiver end of the 
test device for all VCCs. 


Reporting Format: 


The results of the AAL5-CRC-ER/Steady Load/Twelve VCCs test SHOULD 
be reported in a form of text and graph. 


The text results SHOULD display the numerical values of the AAL5-— 
CRC-ER. The values given SHOULD include: time period of test in 
s, test VPI/VCI value, total number of AAL5 PDU’s transmitted and 
received on the given VPI/VCI during the test in positive 
integers, and the AAL5-CRC-ER for the entire test. 


The graph results SHOULD display the AAL5 CRC error ratio values. 
The x-coordinate SHOULD be the test run time in either seconds, 
minutes or days depending on the total length of the test. The 
x-coordinate time SHOULD be configurable. The y-coordinate SHOULD 
be the AAL5-CRC-ER for each VCC. There should be 12 curves on the 
graph, on curve indicated and labeled for each VCC. The 
integration time per point MUST be indicated. 


The results MUST also indicate the packet size in octets, traffic 
rate in packets per second, and bearer class as generated by the 
test device. The VCC and VPI/VCI values MUST be indicated. The 
PCR, SCR, and MBS MUST be indicated. The bearer class of the 
created VCC MUST be indicated. The generated bit pattern MUST 
also be indicated. 


3.3.3.4. AAL5-CRC-ER/Steady Load/Maximum VCCs 


Objective: To determine the SUT ratio of AAL5 CRC PDU errors with the 
maximum number VCCs supported on the SUT in a transmission in 
relation to the total AAL5 PDU’s sent as defined in RFC 2761 
"Terminology for ATM Benchmarking". 


Procedure: 


1) 


Set up the SUT and test device using the bi-directional 
configuration. 


Configure the SUT and test device with the maximum number of VCCs 
supported on the SUT. For example, if the maximum number of VCCs 


Dunn & Martin Informational [Page 97] 


RFC 3116 Methodology for ATM Benchmarking June 2001 


5) 


supported on the SUT is 1024, define 256 VPIs with 4 VCIs per 
VPI. The VCC’s MUST be configured as either a CBR, VBR, or UBR 
connection. The VPI/VCIs MUST not be one of the reserved ATM 
signaling channels (e.g., [0,5], [0,16]). 


Send a specific number of IP packets containing one of the 
specified bit patterns at a constant rate through the SUT via the 
defined test VCCs. All of the VPI/VCI pairs will generate 
traffic at the same traffic rate. Since this test is not a 
throughput test, the rate should not be greater than 90% of line 
rate. The IP PDUs MUST be encapsulated in AALD5. 


Count the IP packets that are transmitted by the SUT on all VCCs 
to verify connectivity and load. If the count on the test device 
is the same on the SUT, continue the test; else lower the test 
device traffic rate until the counts are the same. 


Record the number of AAL5 CRC errors at the receiver end of the 
test device for all VCCs. 


Reporting Format: 


The results of the AAL5-CRC-ER/Steady Load/Maximum VCCs test 
SHOULD be reported in a form of text and graph. 


The text results SHOULD display the numerical values of the AAL5-— 
CRC-ER. The values given SHOULD include: time period of test in 
s, test VPI/VCI value, total number of AAL5 PDU’s transmitted and 
received on the given VPI/VCI during the test in positive 
integers, and the AAL5-CRC-ER for the entire test. 


The graph results SHOULD display the AAL5 CRC error ratio values. 
There will be (Max number of VCCs/10) graphs, with 10 VCCs 
indicated on each graph. The x-coordinate SHOULD be the test run 
time in either seconds, minutes or days depending on the total 
length of the test. The x-coordinate time SHOULD be configurable. 
The y-coordinate SHOULD be the AAL5-CRC-ER for each VCC. There 
SHOULD be no more than 10 curves on each graph, one curve 
indicated and labeled for each VCC. The integration time per 
point MUST be indicated. 


The results MUST also indicate the packet size in octets, traffic 
rate in packets per second, and bearer class as generated by the 
test device. The VCC and VPI/VCI values MUST be indicated. The 
PCR, SCR, and MBS MUST be indicated. The bearer class of the 
created VCC MUST be indicated. The generated bit pattern MUST 
also be indicated. 
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3.3.3.5. AAL5-CRC-ER/Bursty VBR Load/One VCC 


Objective: To determine the SUT ratio of AAL5 CRC PDU errors on one 
VCC in a transmission in relation to the total AAL5 PDU’s sent as 
defined in RFC 2761 "Terminology for ATM Benchmarking". 


Procedure: 


1) 


5) 


Set up the SUT and test device using the bi-directional 
configuration. 


Configure the SUT and test device with one VCC. The VCC SHOULD 
contain one VPI/VCI. The VCC MUST be configured as either a CBR 
or VBR connection. The VPI/VCI MUST not be one of the reserved 
ATM signaling channels (e.g., [0,5], [0,16]). The PCR, SCR, and 
MBS must be configured using one of the specified traffic 
descriptors. 


Send a specific number of IP packets containing one of the 
specified bit patterns at a specific VBR rate through the SUT via 
the defined test VCC. Since this test is not a throughput test, 
the rate should not be greater than 90% of line rate. The IP 
PDUs MUST be encapsulated in AAL5. 


Count the IP packets that are transmitted by the SUT to verify 
connectivity and load. If the count on the test device is the 
same on the SUT, continue the test; else lower the test device 
traffic rate until the counts are the same. 


Record the number of AAL5 CRC errors at the receiver end of the 
test device. 


Reporting Format: 


The results of the AAL5-CRC-ER/Bursty VBR Load/One VCC test SHOULD 
be reported in a form of text and graph. 


The text results SHOULD display the numerical values of the AAL5-— 
CRC-ER. The values given SHOULD include: time period of test in 
s, test VPI/VCI value, total number of AAL5 PDU’s transmitted and 
received on the given VPI/VCI during the test in positive 
integers, and the AAL5-CRC-ER for the entire test. 


The graph results SHOULD display the AAL5 CRC error ratio values. 
The x-coordinate SHOULD be the test run time in either seconds, 
minutes or days depending on the total length of the test. The 
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x-coordinate time SHOULD be configurable. The y-coordinate SHOULD 
be the AAL5-CRC-ER. The integration time per point MUST be 
indicated. 


The results MUST also indicate the packet size in octets, traffic 
rate in packets per second, and bearer class as generated by the 
test device. The VCC and VPI/VCI values MUST be indicated. The 
PCR, SCR, and MBS MUST be indicated. The bearer class of the 
created VCC MUST be indicated. The generated bit pattern MUST 
also be indicated. 


3.3.3.6. AAL5-CRC-ER/Bursty VBR Load/Twelve VCCs 


Objective: To determine the SUT ratio of AAL5 CRC PDU errors on 
twelve VCC’s in a transmission in relation to the total AAL5 PDU’s 
sent as defined in RFC 2761 "Terminology for ATM Benchmarking". 


Procedure: 


1) 


Set up the SUT and test device using the bi-directional 
configuration. 


Configure the SUT and test device with twelve VCCs, using 1 VPI 
and 12 VCIs. The VCC’s MUST be configured as either a CBR or VBR 
connection. The VPI/VCIs MUST not be one of the reserved ATM 
signaling channels (e.g., [0,5], [0,16]). The PCR, SCR, and MBS 
must be configured using one of the specified traffic 
descriptors. 


Send a specific number of IP packets containing one of the 
specified bit patterns at a specific VBR rate through the SUT via 
the defined test vCCs. All of the VPI/VCI pairs will generate 
traffic at the same traffic rate. Since this test is not a 
throughput test, the rate should not be greater than 90% of line 
rate. The PCR, SCR, and MBS must be indicated. The IP PDUs MUST 
be encapsulated in AAL5. 


Count the IP packets that are transmitted by the SUT on all VCCs 
to verify connectivity and load. If the count on the test device 
is the same on the SUT, continue the test; else lower the test 
device traffic rate until the counts are the same. 


Record the number of AAL5 CRC errors at the receiver end of the 
test device for all VCCs. 
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Reporting Format: 


The results of the AAL5-CRC-ER/Bursty VBR Load/Twelve VCCs test 
SHOULD be reported in a form of text and graph. 


The text results SHOULD display the numerical values of the AAL5-— 
CRC-ER. The values given SHOULD include: time period of test in 
s, test VPI/VCI value, total number of AAL5 PDU’s transmitted and 
received on the given VPI/VCI during the test in positive 
integers, and the AAL5-CRC-ER for the entire test. 


The graph results SHOULD display the AAL5 CRC error ratio values. 
The x-coordinate SHOULD be the test run time in either seconds, 
minutes or days depending on the total length of the test. The 
x-coordinate time SHOULD be configurable. The y-coordinate SHOULD 
be the AAL5-CRC-ER for each VCC. There should be 12 curves on the 
graph, on curve indicated and labeled for each VCC. The 
integration time per point MUST be indicated. 


The results MUST also indicate the packet size in octets, traffic 
rate in packets per second, and bearer class as generated by the 
test device. The VCC and VPI/VCI values MUST be indicated. The 
PCR, SCR, and MBS MUST be indicated. The bearer class of the 
created VCC MUST be indicated. The generated bit pattern MUST 
also be indicated. 


3.3.3.7. AAL5-CRC-ER/Bursty VBR Load/Maximum VCCs 


Objective: To determine the SUT ratio of AAL5 CRC PDU errors with the 
maximum number VCCs supported on the SUT in a transmission in 
relation to the total AAL5 PDU’s sent as defined in RFC 2761 
"Terminology for ATM Benchmarking". 


Procedure: 


1) 


Set up the SUT and test device using the bi-directional 
configuration. 


Configure the SUT and test device with the maximum number of VCCs 
supported on the SUT. For example, if the maximum number of VCCs 
supported on the SUT is 1024, define 256 VPIs with 4 VCIs per 
VPI. The VCC’s MUST be configured as either a CBR or VBR 
connection. The VPI/VCIs MUST not be one of the reserved ATM 
signaling channels (e.g., [0,5], [0,16]). The PCR, SCR, and MBS 
must be configured using one of the specified traffic 
descriptors. 
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3) 


5) 


Send a specific number of IP packets containing one of the 
specified bit patterns at a specific VBR rate through the SUT via 
the defined test VCCs. All of the VPI/VCI pairs will generate 
traffic at the same traffic rate. Since this test is not a 
throughput test, the rate should not be greater than 90% of line 
rate. The IP PDUs MUST be encapsulated in AALD5. 


Count the IP packets that are transmitted by the SUT on all VCCs 
to verify connectivity and load. If the count on the test device 
is the same on the SUT, continue the test; else lower the test 
device traffic rate until the counts are the same. 


Record the number of AAL5 CRC errors at the receiver end of the 
test device for all VCCs. 


Reporting Format: 


The results of the AAL5-CRC-ER/Bursty VBR Load/Maximum VCCs test 
SHOULD be reported in a form of text and graph. 


The text results SHOULD display the numerical values of the AAL5-— 
CRC-ER. The values given SHOULD include: time period of test in 
s, test VPI/VCI value, total number of AAL5 PDU’s transmitted and 
received on the given VPI/VCI during the test in positive 
integers, and the AAL5-CRC-ER for the entire test. 


The graph results SHOULD display the AAL5 CRC error ratio values. 
There will be (Max number of VCCs/10) graphs, with 10 VCCs 
indicated on each graph. The x-coordinate SHOULD be the test run 
time in either seconds, minutes or days depending on the total 
length of the test. The x-coordinate time SHOULD be configurable. 
The y-coordinate SHOULD be the AAL5-CRC-ER for each VCC. There 
SHOULD be no more than 10 curves on each graph, one curve 
indicated and labeled for each VCC. The integration time per 
point MUST be indicated. 


The results MUST also indicate the packet size in octets, traffic 
rate in packets per second, and bearer class as generated by the 
test device. The VCC and VPI/VCI values MUST be indicated. The 
PCR, SCR, and MBS MUST be indicated. The bearer class of the 
created VCC MUST be indicated. The generated bit pattern MUST 
also be indicated. 


3.3.3.8. AAL5-CRC-ER/Mixed Load/Three VCC’s 


Objective: To determine the SUT ratio of AAL5 CRC PDU errors on three 
vcc’s in a transmission in relation to the total AAL5 PDU’s sent as 
defined in RFC 2761 "Terminology for ATM Benchmarking". 
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Procedure: 


1) 


5) 


Set up the SUT and test device using the bi-directional 
configuration. 


Configure the SUT and test device with three VCC’s. Each VCC 
MUST be defined as a different Bearer class; one CBR, one UBR and 
one VBR. Each VCC SHOULD contain one VPI/VCI. The VPI/VCI MUST 
not be one of the reserved ATM signaling channels (e.g., [0,5], 
[0,16]). 


Send a specific number of IP packets containing one of the 
specified bit patterns through the SUT via the defined test VCCs. 
Each generated VCC stream MUST match the corresponding VCC Bearer 
class. All of the VPI/VCI pairs will generate traffic at the 
same traffic rate. Since this test is not a throughput test, the 
rate should not be greater than 90% of line rate. The IP PDUs 
MUST be encapsulated in AAL5. 


Count the IP packets that are transmitted by the SUT to verify 
connectivity and load. If the count on the test device is the 
same on the SUT, continue the test; else lower the test device 
traffic rate until the counts are the same. 


Record the number of AAL5 CRC errors at the receiver end of the 
test device for all VCCs. 


Reporting Format: 


The results of the AAL5-CRC-ER/Bursty Mixed Load/Three VCCs test 
SHOULD be reported in a form of text and graph. 


The text results SHOULD display the numerical values of the AAL5-— 
CRC-ER. The values given SHOULD include: time period of test in 
s, test VPI/VCI value, total number of AAL5 PDU’s transmitted and 
received on the given VPI/VCI during the test in positive 
integers, and the AAL5-CRC-ER for the entire test. 


The graph results SHOULD display the AAL5 CRC error ratio values. 
The x-coordinate SHOULD be the test run time in either seconds, 
minutes or days depending on the total length of the test. The 
x-coordinate time SHOULD be configurable. The y-coordinate SHOULD 
be the AAL5-CRC-ER for each VCC. There should be 12 curves on the 
graph, on curve indicated and labeled for each VCC. The 
integration time per point MUST be indicated. 


The results MUST also indicate the packet size in octets, traffic 
rate in packets per second, and bearer class as generated by the 
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test device. The VCC and VPI/VCI values MUST be indicated. The 
PCR, SCR, and MBS MUST be indicated. The bearer class of the 
created VCC MUST be indicated. The generated bit pattern MUST 
also be indicated. 


3.3.3.9. AAL5-CRC-ER/Mixed Load/Twelve VCCs 


Objective: To determine the SUT ratio of AAL5 CRC PDU errors on 
twelve VCC’s in a transmission in relation to the total AAL5 PDU’s 
sent as defined in RFC 2761 "Terminology for ATM Benchmarking". 


Procedure: 


1) 


5) 


Set up the SUT and test device using the bi-directional 
configuration. 


Configure the SUT and test device with twelve VCC’s. Each VCC 
MUST be defined as one of the Bearer classes for a total of four 
CBR, four UBR and four VBR VCC’s. Each VCC SHOULD contain one 
VPI/VCI. The VPI/VCI MUST not be one of the reserved ATM 
signaling channels (e.g., [0,5], [0,16]). 


Send a specific number of IP packets containing one of the 
specified bit patterns through the SUT via the defined test VCCs. 
Each generated VCC stream MUST match the corresponding VCC Bearer 
class. All of the VPI/VCI pairs will generate traffic at the 
same traffic rate. Since this test is not a throughput test, the 
rate should not be greater than 90% of line rate. The IP PDUs 
MUST be encapsulated in AAL5. 


Count the IP packets that are transmitted by the SUT on all VCCs 
to verify connectivity and load. If the count on the test device 
is the same on the SUT, continue the test; else lower the test 
device traffic rate until the counts are the same. 


Record the number of AAL5 CRC errors at the receiver end of the 
test device for all VCCs. 


Reporting Format: 


The results of the AAL5-CRC-ER/Bursty Mixed Load/Twelve VCCs test 
SHOULD be reported in a form of text and graph. 


The text results SHOULD display the numerical values of the AAL5-— 
CRC-ER. The values given SHOULD include: time period of test in 
s, test VPI/VCI value, total number of AAL5 PDU’s transmitted and 
received on the given VPI/VCI during the test in positive 
integers, and the AAL5-CRC-ER for the entire test. 
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The graph results SHOULD display the AAL5 CRC error ratio values. 
The x-coordinate SHOULD be the test run time in either seconds, 
minutes or days depending on the total length of the test. The 
x-coordinate time SHOULD be configurable. The y-coordinate SHOULD 
be the AAL5-CRC-ER for each VCC. There should be 12 curves on the 
graph, on curve indicated and labeled for each VCC. The 
integration time per point MUST be indicated. 


The results MUST also indicate the packet size in octets, traffic 
rate in packets per second, and bearer class as generated by the 
test device. The VCC and VPI/VCI values MUST be indicated. The 
PCR, SCR, and MBS MUST be indicated. The bearer class of the 
created VCC MUST be indicated. The generated bit pattern MUST 
also be indicated. 


3.3.3.10. AAL5-CRC-ER/Mixed Load/Maximum VCCs 


Objective: To determine the SUT ratio of AAL5 CRC PDU errors with the 
maximum number VCCs supported on the SUT in a transmission in 
relation to the total AAL5 PDU’s sent as defined in RFC 2761 
"Terminology for ATM Benchmarking". 


Procedure: 


1) 


Set up the SUT and test device using the bi-directional 
configuration. 


Configure the SUT and test device with maximum number of VCCs 
supported on the SUT. For example, if the maximum number of VCCs 
supported on the SUT is 1024, define 256 VPIs with 4 VCIs per 
VPI. Each VCC MUST be defined as one of the Bearer classes for a 
total of (max VCC/3) CBR, (max VCC/3) UBR and (max VCC/3) VBR 
vcc’s. The VPI/VCI MUST not be one of the reserved ATM signaling 
channels (e.g., [0,5], [0,16]). 


Send a specific number of IP packets containing one of the 
specified bit patterns through the SUT via the defined test VCCs. 
Each generated VCC stream MUST match the corresponding VCC Bearer 
class. All of the VPI/VCI pairs will generate traffic at the 
same traffic rate. Since this test is not a throughput test, the 
rate should not be greater than 90% of line rate. The IP PDUs 
MUST be encapsulated in AAL5. 


Count the IP packets that are transmitted by the SUT on all VCCs 
to verify connectivity and load. If the count on the test device 
is the same on the SUT, continue the test; else lower the test 
device traffic rate until the counts are the same. 
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5) 


Record the number of AAL5 CRC errors at the receiver end of the 
test device for all VCCs. 


Reporting Format: 


3.4. 


BA wh. 


The results of the AAL5-CRC-ER/Bursty Mixed Load/Maximum VCCs test 
SHOULD be reported in a form of text and graph. 


The text results SHOULD display the numerical values of the AAL5-— 
CRC-ER. The values given SHOULD include: time period of test in 
s, test VPI/VCI value, total number of AAL5 PDU’s transmitted and 
received on the given VPI/VCI during the test in positive 
integers, and the AAL5-CRC-ER for the entire test. 


The graph results SHOULD display the AAL5 CRC error ratio values. 
There will be (Max number of VCCs/10) graphs, with 10 VCCs 
indicated on each graph. The x-coordinate SHOULD be the test run 
time in either seconds, minutes or days depending on the total 
length of the test. The x-coordinate time SHOULD be configurable. 
The y-coordinate SHOULD be the AAL5-CRC-ER for each VCC. There 
SHOULD be no more than 10 curves on each graph, one curve 
indicated and labeled for each VCC. The integration time per 
point MUST be indicated. 


The results MUST also indicate the packet size in octets, traffic 
rate in packets per second, and bearer class as generated by the 
test device. The VCC and VPI/VCI values MUST be indicated. The 
PCR, SCR, and MBS MUST be indicated. The bearer class of the 
created VCC MUST be indicated. The generated bit pattern MUST 
also be indicated. 


ATM Service: Signaling 


CAC Denial Time and Connection Establishment Time 


Objective: To determine the CAC rejection time and Connection 
Establishment Time on the SUT as defined in RFC 2761 "Terminology for 
ATM Benchmarking". 


Procedure: 


1) 


Set up the SUT and test device using the bi-directional 
configuration. 


Create a UNI signaling setup message, as described in Appendix C, 
specifying a PCR which will not allow CAC to reject the call. 
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3x 


4 


3) 


Send the UNI signaling setup message. Note the time the setup 
message was sent. Verify that the SVC has been setup with the 
correct parameters. Note the time the connect message was 
received 


Create a UNI signaling setup message, as described in Appendix C, 
specifying a PCR which will allow CAC to reject the call. 


Send the UNI signaling setup message. Note the time the setup 
message was sent. Verify that the SVC has been rejected with the 
correct cause code. Note the time the release complete message 
was received. 


Compute the rejection time as the difference between the time the 
release complete message was received and the time setup message 
was send. 


Reporting Format: 


Dee 


The results of the CAC Denial Time and Connection Establishment 
Time tests SHOULD be reported in a form of a table. The rows 
SHOULD be labeled call accepted and call rejected. The columns 
SHOULD be labeled time setup sent, time response received, and 
correct response. The elements of the columns 1 and 2 SHOULD be 
in seconds. The elements of column 3 SHOULD be be either True or 
False, indicating whether the particular condition was observed 
for each test. 


The table MUST also indicate the packet size in octets and traffic 
rate in packets per second as generated by the test device. 


Connection Teardown Time 


Objective: To determine the Connection Teardown Time on the SUT as 
defined in RFC 2761 "Terminology for ATM Benchmarking". 


Procedure: 


1) 


Set up the SUT and test device using the bi-directional 
configuration. 


Create a UNI signaling setup message, as described in Appendix C, 
specifying a PCR which will not allow CAC to reject the call. 


Send the UNI signaling setup message. Note the time the setup 
message was sent. Verify that the SVC has been setup with the 
correct parameters. Note the time the connect message was 
received 
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Create a UNI signaling release message, as described in Appendix 
C, specifying a cause code of normal call clearing. 


Send the UNI signaling release message. Note the time the 
release message was sent. Verify that the SVC has been 
terminated with the correct cause code. Note the time the 
release complete message was received. 


Compute the release time as the difference between the time the 
release complete message was received and the time release 
message was send. 


Reporting Format: 


3:3 AN Si 


The results of the Connection Teardown Time tests SHOULD be 
reported in a form of a table. The rows SHOULD be labeled call 
accepted and call released. The columns SHOULD be labeled time 
message sent, time response received, and correct response. The 
elements of the columns 1 and 2 SHOULD be in seconds. The 
elements of column 3 SHOULD be be either True or False, indicating 
whether the particular condition was observed for each test. 


The table MUST also indicate the packet size in octets and traffic 
rate in packets per second as generated by the test device. 


Crankback Time 


Objective: To determine the Crankback Time on the SUT as defined in 
RFC 2761 "Terminology for ATM Benchmarking". 


Procedure: 


1) 


Set up the SUT and test device using the uni-directional 
passthrough configuration. 


Create a PNNI signaling setup message, as described in Appendix 
C, specifying a DTL which is not blocked by the far end SUT. 


Send the PNNI signaling setup message. Note the time the setup 
message was sent. Verify that the connect message has been 
received by the near-end switch. Note the time the connect 
message was received 


Create a PNNI signaling setup message, as described in Appendix 
C, specifying a DTL which is blocked by the far end SUT. 


Send the PNNI signaling release message. Note the time the 
release message was sent. Note the time the release complete 
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message was received. Note the time the near-end switch sends 
it’s own PNNI setup message (referred to as the near-end setup 
message) specifying the non- blocked DTL. 


Compute the crankback time as the difference between the time the 
near-end setup message was received and the time release message 
was send. 


Reporting Format: 


38 AeA: 


The results of the Crankback Time tests SHOULD be reported ina 
form of a table. The rows SHOULD be labeled DTL call accepted and 
call released. The columns SHOULD be labeled time message sent, 
time response received, and correct response. The elements of the 
columns 1 and 2 SHOULD be in seconds. The elements of column 3 
SHOULD be be either True or False, indicating whether the 
particular condition was observed for each test. 


The table MUST also indicate the packet size in octets and traffic 
rate in packets per second as generated by the test device. 


Route Update Response Time 


Objective: To determine the Route Update Response Time on the SUT as 
defined in RFC 2761 "Terminology for ATM Benchmarking". 


Procedure: 


1) 


Set up the SUT and test device using the uni-directional 
passthrough configuration. 


Create a PNNI PTSE as described in Appendix C, specifying a 
routing topology. Verify that the routing tables on the far-end 
and near-end switches are empty. 


Send the PTSE message to the far-end switch. Note the time the 
PTSE message was sent. Verify that the PTSE message has been 
received by the far-end switch. Note the time the PTSE message 
was received. 


Create another PNNI PTSE as described in Appendix C, specifying a 
change in the routing topology. Verify that the routing tables 
on the far-end and near-end switches contain the previous PTSE 
routes. 


Send the PTSE message to the far-end switch. Note the time the 
PTSE message was sent. Verify that the PTSE message has been 
received by the far-end switch. Note the time the PTSE message 
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was received. Note the time the PTSE was sent to the near-end 
switch. Note the time the PTSE message was received on the 
near-end switch. 


Compute the Route Update Response time as the difference between 
the time the far-end PTSE message was sent and the time far-end 
PTSE message was received by the near-end. 


Reporting Format: 


36's 


Siedie di 


The results of the Route Update Response Time tests SHOULD be 
reported in a form of a table. The rows SHOULD be labeled PTSE 
call accepted, far-end PTSE message send, and near-end message 
received. The columns SHOULD be labeled time message sent, time 
response received, and correct response. The elements of the 
columns 1 and 2 SHOULD be in seconds. The elements of column 3 
SHOULD be be either True or False, indicating whether the 
particular condition was observed for each test. 


The table MUST also indicate the packet size in octets and traffic 
rate in packets per second as generated by the test device. 


ATM Service: ILMI 


MIB Alignment Time 


Objective: To determine the MIB Alignment Time on the SUT as defined 
in RFC 2761 "Terminology for ATM Benchmarking". 


Procedure: 


1) 


Set up the SUT and test device using the bi-directional 
configuration. 


Send a Cold Start message to the SUT. Note the time the message 
was sent to the SUT. Verify that the Cold Start message has been 
received by the SUT. Note the time the message was received. 


Send a Get Request message to the SUT. Note the time the message 
was sent to the SUT. Verify that the Get Request message has 
been received by the SUT. Note the time the message was 
received. 


After all MIB elements are exchanged, verify that the final Get 
Request message has been received by the SUT. Note the time the 
message was send and received by the SUT. 
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5) 


Compute the MIB Alignment Time as the difference between the time 
the Cold Start message was sent and the time the final Get 
Request was received by the SUT. 


Reporting Format: 


BD a2. 


The results of the MIB Alignment Time tests SHOULD be reported in 
a form of a table. The rows SHOULD be labeled Cold Start Send, 
Cold Start accepted, Final Get Request send, and Final Get Request 
received. The columns SHOULD be labeled time message sent, time 
response received, and correct response. The elements of the 
columns 1 and 2 SHOULD be in seconds. The elements of column 3 
SHOULD be be either True or False, indicating whether the 
particular condition was observed for each test. 


The table MUST also indicate the packet size in octets and traffic 
rate in packets per second as generated by the test device. 


Address Registration Time 


Objective: To determine the Address Registration Time on the SUT as 
defined in RFC 2761 "Terminology for ATM Benchmarking". 


Procedure: 


1) 


Set up the SUT and test device using the bi-directional 
configuration. 


Send a Set Request message to the SUT. Note the time the message 
was sent to the SUT. Verify that the Set Request message has 
been received by the SUT. Note the time the message was 
received. 


Send a Get Request message to the SUT. Note the time the message 
was sent to the SUT. Verify that the Get Request message has 
been received by the SUT. Note the time the message was 
received. 


After all MIB elements are exchanged, verify that the final Get 
Request message has been received by the SUT. Note the time the 
message was send and received by the SUT. 


Compute the Address Registration Time as the difference between 
the time the Set Request message was sent and the time the final 
Get Request was received by the SUT. 
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Reporting Format: 


The results of the Address Registration Time tests SHOULD be 
reported in a form of a table. The rows SHOULD be labeled Set 
Request Send, Set Request accepted, Final Get Request send, and 
Final Get Request received. The columns SHOULD be labeled time 
message sent, time response received, and correct response. The 
elements of the columns 1 and 2 SHOULD be in seconds. The 
elements of column 3 SHOULD be be either True or False, indicating 
whether the particular condition was observed for each test. 


The table MUST also indicate the packet size in octets and traffic 
rate in packets per second as generated by the test device. 


4. Security Considerations 


As this document is solely for the purpose of providing methodology 
and describes neither a protocol nor an implementation, there are no 
security considerations associated with this document. 


5. Notices 


The IETF takes no position regarding the validity or scope of any 
intellectual property or other rights that might be claimed to 
pertain to the implementation or use of the technology described in 
this document or the extent to which any license under such rights 
might or might not be available; neither does it represent that it 


has made any effort to identify any such rights. Information on the 
IETFs procedures with respect to rights in standards-track and 
standards-related documentation can be found in BCP-11. Copies of 


claims of rights made available for publication and any assurances of 
licenses to be made available, or the result of an attempt made to 
obtain a general license or permission for the use of such 
proprietary rights by implementors or users of this specification can 
be obtained from the IETF Secretariat. 


The IETF invites any interested party to bring to its attention any 
copyrights, patents or patent applications, or other proprietary 
rights which may cover technology that may be required to practice 
this standard. Please address the information to the IETF Executive 
Director. 


Dunn & Martin Informational [Page 112] 


RFC 3116 


6. References 


[RFC2544] 


[RFC2225] 


[RFC2761] 


[AF-ILMT4.0] 


[AF-TEST-0022] 


[AF-TM4.1] 


[AF-UNI3.1] 


[AF-UNI4.0] 


Methodology for ATM Benchmarking June 2001 


Bradner, S. and J. McQuaid, "Benchmarking Methodology 
for Network Interconnect Devices", RFC 2544, March 
1999; 


Laubach, M. and J. Halpern, "Classical IP and ARP over 
ATM", RFC 2225, April 1998. 


Dunn, J. and C. Martin, "Terminology for ATM 
Benchmarking", RFC 2761, February 2000. 


ATM Forum Integrated Local Management Interface 
Version 4.0, af-ilmi-0065.000, September 1996. 


Introduction to ATM Forum Test Specifications, af- 
test-0022.00, December 1994. 


ATM Forum, Traffic Management Specification Version 
4.1, af-tm-0121.00, April 1996. 


ATM Forum, User Network Interface Specification 
Version 3.1, September 1994. 


ATM Forum, User Network Interface Specification 
Version 4.0, July 1996. 


7. Authors’ Addresses 


Jeffrey Dunn 
Advanced Network Consultants, Inc. 
4214 Crest Place 

Ellicott City, 


Phone: +1 


(410) 


MD 21043, USA 


750-1700 


EMail: Jeffrey.Dunn@worldnet.att.net 


Cynthia Martin 
Advanced Network Consultants, Inc. 
4214 Crest Place 

Ellicott City, 


Phone: +1 


(410) 


MD 21043, USA 


750-1700 


EMail: Cynthia.E.Martin@worldnet.att.net 


Dunn & Martin 


Informational [Page 113] 


RFC 3116 Methodology for ATM Benchmarking June 2001 


Appendix A: Ranges 


ATM NSAP Network Prefix. 
39 0000 0000 0000 0000 0000 0000-39 0000 0000 0000 0000 0000 OOFF 
39 0000 0000 0000 0000 0001 0000-39 0000 0000 0000 0000 0001 OOFF 
39 0000 0000 0000 0001 0000 0000 
39 0000 0000 0000 0002 0020 0000 
39 0000 0000 0300 0002 0030 0000 
39 0000 0000 4000 0002 0060 0000 
39 0000 0006 0060 0002 0030 0000 
39 0000 0006 0050 0002 0030 0000 
39 0000 0009 0300 0002 0030 0000 
39 0000 00A0 0300 0002 0030 0000 
39 0000 0B00 0300 0002 0030 0000 
39 0000 C000 0300 0002 0030 0000 


ATM NSAP End System Identifier. 
1111 1111 1111 00-1111 1111 11FF 00 
2222 2222 2000 00-2222 2222 2222 00 
9999 999A 0000 00-9999 999C 0000 00 
Appendix B: Rates 
PNNI Routing Update Size. 
1) 1 PNNI routing entry update on non-aggregated addresses 
2) 2 PNNI routing entry updates on non-aggregated addresses 


3) 5 PNNI routing entry updates on non-aggregated addresses 


4) 1 % of total available bandwidth or 1 Mb/s, whichever is less on 
non- aggregated addresses 


5) 1 % of total available bandwidth or 1 Mb/s, whichever is less on 
of non-aggregated addresses and of aggregated addresses 


6) 1 % of total available bandwidth or 1 Mb/s, whichever is less on 
aggregated addresses 


7) 2 % of total available bandwidth or 2 Mb/s, whichever is less on 
non- aggregated addresses 


8) 2 % of total available bandwidth or 2 Mb/s, whichever is less on 
of non-aggregated addresses and of aggregated addresses 


9) 2 % of total available bandwidth or 2 Mb/s, whichever is less on 
aggregated addresses 
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PNNI Routing Update Repetition Interval. 


Repetition Interval begins after initial PNNI routing table 


stabilizes. 


1) 1 update every 1 hour, 


for 24 hours 


2) 1 update every 30 minutes, for 24 ho 


3) 1 update every 5 minutes, for 1 hour 


4) 1 update every 1 minute, for 15 minu 


5) 1 update every 30 seconds, for 5 min 


6) 1 update every 30 seconds, for 1 min 


7) 1 update every 1 second, for 30 seco 


Maximum WAN Connection rates in packets per second (pps): 


25.6 

IP Packet Size 

octets/cells 

44/2 30188 
64/2 30188 
128/3 20125 
256/6 10062 
1024/22 2744 
1518/32 1886 
2048/43 1404 
4472/94 642 
9180/192 314 


Maximum LAN Connection rates in packets per second (pps): 


DS-1 
IP Packet Size 
octets/cells 

44/2 1811 
64/2 1811 
128/3 1207 
256/6 603 
1024/22 164 
1518/32 113 
2048/43 84 
4472/94 38 
9180/192 18 


Dunn & Martin 


OC-3c 


176603 
176603 
117735 
58867 
16054 
11037 
8214 
3757 
1839 


DS-3 


52133 
52133 
34755 
17377 
4739 
3258 
2424 
1109 
543 


Informational 


urs 


tes 


utes 


ute 


nds 


OC-12c 


706412 
706412 
470940 
235468 
64216 
44148 
32856 
15028 
7356 


El 


2340 
2340 
1560 
780 
212 
146 
108 
49 
24 


E3 


40000 
40000 
26666 
13333 
3636 
2500 
1860 
851 
416 
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Notes: 1. PDU size in cells is computed based on ceiling( ( PDU size 
in octets + 16) / 48). This assumes an 8 octet LLC/SNAP header and 
an 8 octet AAL/5 trailer. 


2. Due to the number of possible configurations, IMA pps rates are 
not listed, but may be derived from the following formula: floor 
(IDCR/cells per packet), where cells per packet is computed as in 
note 1. 


3. The following cell rates were used: DS-1 = 3622 cps (using ATM TC) 
El = 4681 cps 25.6 Mb/s = 60377 cps E3 = 80000 cps (using ATM TC) 
DS-3 = 104266 cps (using ATM TC) OC-3c = 353207 cps OC-12c = 1412828 
cps 


Appendix C: PDU’s 


TCP/IP over ATM Example 1. 


LLC: DSAP OxAA (SNAP-SAP) 
SSAP OxAA (SNAP-SAP) 
Control 0x03 (Unnumbered Information) 
SNAP: OUI 0x00-00-00 (Ethertype) 
PID 0x0800 (Internet Protocol) 
IP: Version = 4 
Header length = 20 
Type of service = 0 
000. .... Precedence = Routine (0) 
-O .... Delay = Normal (0) 
0... Throughput = Normal (0) 


.... .0.. Reliability = Normal (0) 
Packet length = 40 


Id = 0 
Fragmentation Info = 0x0000 
-O.. «2... «22. «--- Don’t Fragment Bit = FALSE 
0 .... More Fragments Bit = FALSE 


...0 0000 0000 0000 Fragment offset = 0 
Time to live = 255 
Protocol = TCP (6) 
Header checksum = F9CF 
Source address = 15.19.209.236 
Destination address = 15.19.209.237 


TCP Source port = smtp (25) 
Destination port = smtp (25) 
Sequence number = 1 
Ack number = 0 


Data offset = 20 
Flags = 0x02 

..0. .... URGENT Flag = FALSE 
.0 .... ACK Flag = FALSE 


Dunn & Martin Informational [Page 116] 


RFC 3116 


TCP/IP over 
ELG: DSAP 


SNAP: 


IP: 


TCP: 
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Oiss 
OR 
aliz 


PUSH Flag 
RST Flag 
SYN Flag 
.0 FIN Flag 


FALSE 
FALSE 
TRUE 
FALSE 


Window 
Checksum EDAF 
Urgent pointer 


o 


= 00000000 

ATM Example 2. 

OxAA (SNAP-SAP) 
OxAA (SNAP-SAP) 
0x03 

0x00-00-00 
0x0800 


SSAP 
Control 
(Ethertype) 
PID (Internet Protocol) 
Version 4 
Header length 20 
Type of service = 0 
000. Precedence 
-0O .... Delay Normal 
0... Throughput 
.... .0.. Reliability 
Packet length 40 
Id 0 
Fragmentation Info 
Oss 
DOG isg 
.0 0000 
Time to live 
Protocol TCP 
Header checksum 
Source address 
Destination address 
Source port ftp-data 
Destination port 2000 
Sequence number 1 


Routine (0) 
(0) 

Normal 
Normal 


(0) 
(0) 


0x0000 
Don’t Fragment Bit 
More Fragments Bit 
0000 0000 Fragment offset 
255 
(6) 


= FALSE 
FALSE 


0 


F9OCF 
15.19.209.236 
15.19.209.237 

(20) 


Ack number = 0 
Data offset = 20 
Flags = 0x02 
0. URGENT Flag = FALSE 
.0 .... ACK Flag = FALSE 
0... PUSH Flag = FALSE 
.0.. RST Flag = FALSE 
.1. SYN Flag = TRUE 
.0 FIN Flag = FALSE 
Window = o 
Checksum = E5FD 
Urgent pointer = 00000000 
Informational 
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UDP/IP over ATM Example. 


LLC: DSAP OxAA (SNAP-SAP) 
SSAP OxAA (SNAP-SAP) 
Control 0x03 (Unnumbered Information) 
SNAP: OUI 0x00-00-00 (Ethertype) 
PID 0x0800 (Internet Protocol) 
IP: Version = 4 
Header length = 20 
Type of service = 0 
000. .... Precedence = Routine (0) 
.0 .... Delay = Normal (0) 
0... Throughput = Normal (0) 


.... .0.. Reliability = Normal (0) 
Packet length = 28 


Id = 0 
Fragmentation Info = 0x0000 
-O.. «2... «2... «.-- Don’t Fragment Bit = FALSE 
--O. .... «2... ...-. More Fragments Bit = FALSE 
...0 0000 0000 0000 Fragment offset = 0 
Time to live = 255 
Protocol = ICMP (1) 
Header checksum = F9EO 
Source address = 15.19.209.236 
Destination address = 15.19.209.237 
ICMP: Type = Echo request (8) 
Code = 0 
Checksum = F7FF 
Identifier = 0 (0x0) 
Sequence Number = 0 (0x0) 
RIP Routing Update over ATM. 
—- DATAGRAM HEADER 
offset data (hex) description 
00 FF FF FF FF FF FF dest MAC address is broadcast 
06 XX XX XX XX XX XX source hardware address 
12 08 00 type 
—— IP HEADER 
14 45 IP version - 4, header length (4 
byte units) - 5 
15 00 service field 
16 00 EE total length 
18 00 00 ID 
20 40 00 flags (3 bits) 4 (do not 


fragment), 
fragment offset-0 
22 OA TTL 
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23 11 protocol - 17 (UDP) 

24 C4 8D header checksum 

26 XX XX XX XX source IP address 

30 XX XX XX destination IP address 

33. FF host part = FF for broadcast 
-- UDP HEADER 

34 02 08 source port 208 = RIP 

36 02 08 destination port 208 = RIP 
38 00 DA UDP message length 

40 00 00 UDP checksum 


-- RIP packet 


42 02 command = response 
43 01 version = 1 

44 00 00 0 

-- net 1 

46 00 02 family = IP 

48 00 00 0 

50 XX XX XX net 1 IP address 
53 00 net not node 

54 00 00 00 00 0 

58 00 00 00 00 0 

62 00 00 00 O07 metric 7 

—- net 2 

66 00 02 family = IP 

68 00 00 (0) 

70 XX XX XX net 2 IP address 
F3 00 net not node 

74 00 00 00 00 0 

78 00 00 00 00 (0 

82 00 00 00 07 metric 7 

—- net 3 

86 00 02 family = IP 

88 00 00 0 

90 XX XX XX net 3 IP address 
93 00 net not node 

94 00 00 00 00 0 

98 00 00 00 00 0 

102 00 00 00 07 metric 7 

—- net 4 

106 00 02 family = IP 

108 00 00 0 
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110 XX XX XX net 4 IP address 
113 00 net not node 

114 00 00 00 00 0 

118 00 00 00 00 0 

122 00 00 00 07 metric 7 

-- net 5 

126 00 02 family = IP 

128 00 00 (0 

130 00 net 5 IP address 
133 00 net not node 

134 00 00 00 00 0 

138 00 00 00 00 0 

142 00 00 00 07 metric 7 

—-- net 6 

146 00 02 family = IP 

148 00 00 (0) 

150 XX XX XX net 6 IP address 
L93 00 net not node 

154 00 00 00 00 (0) 

158 00 00 00 00 0 

162 00 00 00 07 metric 7 


UNI 3.1 Signaling Setup Message Example. PCR will not allow CAC to 
reject the call. 


Protocol Discriminator : Q.93B UNI call control 
Call Reference Length eS 

Call Reference Flag : orig 

Call Reference Value = 10 

Message Type : SETUP 

Ext : last octet 

Action Indicator : clear call 

Message Length : 50 

Information Element ID : ATM Traffic Descriptor 
Ext : last octet 

Coding Standard : ITU-T standard 

Action Indicator : clear call 

IE Length E9 

Cell Rate Subfield ID : forward peak CR(CLP=0+1) 
Forward Peak Cell Rate fo) 

Cell Rate Subfield ID : backward peak CR(CLP=0+1) 
Backward Peak Cell Rate Zal 

Cell Rate Subfield ID : best effort indicator 
Information Element ID : Broadband Bearer Capability 
Ext : last octet 

Coding Standard : ITU-T standard 
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Action Indicator 

IE Length 

Ext 

Bearer Class 

Ext 

Clipping Susceptibility 


User Plane Connection CFG 


Information Element ID 
Ext 

Coding Standard 
Action Indicator 

IE Length 

Ext 


Addressing/Numbering Plan 


ISO NSAP Address Octets 
Information Element ID 
Ext 

Coding Standard 

Action Indicator 

IE Length 

QoS Class Forward 

QoS Class Backward 


UNI 3.1 Signaling Setup Message Reject Example. PCR will 


CAC to reject the call. 


Protocol Discriminator 
Call Reference Length 
Call Reference Flag 
Call Reference Value 
Message Type 

Ext 

Action Indicator 
Message Length 
Information Element ID 
Ext 

Coding Standard 
Action Indicator 

IE Length 

Cell Rate Subfield ID 
Forward Peak Cell Rate 
Cell Rate Subfield ID 
Backward Peak Cell Rate 
Information Element ID 
Ext 

Coding Standard 

Flag 

Action Indicator 
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clear call 

2 

last octet 

BCOB-X 

last octet 

not susceptible to clipping 
point-to-point 
Called Party Number 
last octet 

ITU-T standard 
clear call 

21 

last octet 

ISO NSAP addressing 


June 2001 


3900000000000000000000000011111111111100 


Quality of Service Parameter 
last octet 

ITU-T standard 

clear call 


2 
QoS class 0 - unspecified 
QoS class 0 - unspecified 


Q.93B UNI call control 
3 

orig 

0 

SETUP 

last octet 

clear call 

50 

ATM Traffic Descriptor 
last octet 

ITU-T standard 

clear call 

8 

forward peak CR(CLP=0+1) 
300000 

backward peak CR(CLP=0+1) 
300000 

Broadband Bearer Capability 
last octet 

ITU-T standard 

not significant 

clear call 


Informational 


allow 
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IE Length 

Ext 

Bearer Class 

Ext 

Traffic Type 

Timing Requirements 

Ext 

Clipping Susceptibility 
User Plane Connection CFG 
Information Element ID 
Ext 

Coding Standard 

Action Indicator 

IE Length 

Ext 
Addressing/Numbering Plan 
ISO NSAP Address Octets 
Information Element ID 
Ext 

Coding Standard 

Action Indicator 

IE Length 

QoS Class Forward 

QoS Class Backward 


UNI 
call clearing. 


Protocol Discriminator 
Call Reference Length 
Call Reference Flag 
Call Reference Value 
Message Type 

Ext 

Action Indicator 
Message Length 
Information Element ID 
Ext 

Coding Standard 
Action Indicator 

IE Length 

Ext 

Location 

Ext 

Cause Value 


PNNI Signaling Setup Message, 


by the far end SUT. 
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3.1 Signaling Release Message, 


Informational 
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3 

another octet 

BCOB-X 

last octet 

constant bit rate 
end-to-end timing required 
last octet 

not susceptible to clipping 
point-to-point 

Called Party Number 

last octet 

ITU-T standard 

clear call 

21 

last octet 

ISO NSAP addressing 
3900000000000000000000000011111111111100 
Quality of Service Parameter 
last octet 

ITU-T standard 

clear call 


2 
QoS class 0 - unspecified 
QoS class 0 - unspecified 


specifying a cause code of normal 


Q.93B UNI call control 
3 

orig 

(0 

RELEASE 

last octet 

clear call 

6 

Cause 

last octet 

ITU-T standard 

clear call 

2 

last octet 

user 

last octet 

NE:normal call clearing 


specifying a DTL which is not blocked 
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Protocol Discriminator 
Call Reference Length 
Call Reference Flag 
Message Type 

Ext 

Pass Along Request 
Action Indicator 
Message Length 
Information Element ID 
Ext 

Coding Standard 

Pass Along Request 
Action Indicator 

IE Length 

Information Element ID 
Ext 

Coding Standard 

Pass Along Request 
Action Indicator 

IE Length 

Ext 

Bearer Class 

Ext 

ATM Transfer Capability 
Ext 

Clipping Susceptibility 
User Plane Connection cfg 
Information Element ID 
Ext 

Coding Standard 

Pass Along Request 
Action Indicator 

IE Length 

Ext 

Type of Number 
Addressing/Numbering Plan 
ATM Endsystem Address Oct 
Information Element ID 
Ext 

Coding Standard 

Pass Along Request 
Action Indicator 

IE Length 

Current Transit Pointer 
Logical Node/Port Indicat 
Logical Node Identifier 
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PNNI signalling 

3 

from 

SETUP 

last octet 

no pass along request 
clear call 

56 

ATM Traffic Descriptor 
last octet 

ITU-T standardized 

no pass along request 
clear call 

0 

Broadband Bearer Capability 
last octet 

ITU-T standardized 

no pass along request 
clear call 

3 

another octet 

BCOB-X 

last octet 

reserved for bwd compatibility 
last octet 

not susceptible to clipping 
point-to-point 

Called Party Number 
last octet 

ITU-T standardized 

no pass along request 
clear call 

8 

last octet 

unknown 

ATM endsystem address 
11111111111101 
Designated Transit List 
last octet 

ATM Forum specific 

no pass along request 
clear call 

29 

0 

Logical Node/Port Indicator 


June 2001 


3900000000000000000000000011111111111100 
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PNNI Signaling Setup Message Reject, 
blocked by the far end SUT. 


specifying a DTL which is 


Protocol Discriminator PNNI signalling 
Call Reference Length 3 
Call Reference Flag from 
Call Reference Value 0 
Message Type SETUP 


Ext 

Pass Along Request 
Action Indicator 
Message Length 
Information Element ID 
Ext 

Coding Standard 

Pass Along Request 
Action Indicator 

IE Length 

Information Element ID 
Ext 

Coding Standard 

Pass Along Request 
Action Indicator 

IE Length 

Bearer Class 

Ext 

ATM Transfer Capability 
Ext 

Clipping Susceptibility 


User Plane Connection cfg 


Information Element ID 
Ext 

Coding Standard 

Pass Along Request 
Action Indicator 

IE Length 

Ext 


Addressing/Numbering Plan 
ATM Endsystem Address Oct 


Information Element ID 
Ext 

Coding Standard 

Pass Along Request 
Action Indicator 

IE Length 

Current Transit Pointer 


last octet 
no pass along request 
clear call 
56 
ATM Traffic Descriptor 
last octet 
ITU-T standardized 
no pass along request 
clear call 
0 
Broadband Bearer Capability 
last octet 
ITU-T standardized 
no pass along request 
clear call 
3 
BCOB-X 
last octet 
reserved for bwd compatibility 
last octet 
not susceptible to clipping 
point-to-point 
Called Party Number 
last octet 
ITU-T standardized 
no pass along request 
clear call 
8 
last octet 
ATM endsystem address 
11111111111101 
Designated Transit List 
last octet 
ATM Forum specific 
no pass along request 
clear call 
29 
0 


Logical Node/Port Indicat 
Logical Node Identifier 


Logical Node/Port Indicator 
3900000000000000000000000011111111111100 
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PNNI Far End Request Message. 


Header: Packet Type 


IG: 


PNNI PTSE, 


Packet Length 

Protocol Version 

Newest Version Supported 
Oldest Version Supported 
Reserved 

Information Group Type 
Information Group Length 
Originating Node ID 


5 
40 
1 
1 
0 
0 


513 
32 


(PTSE REQUEST) 


June 2001 


(Requested PTSE Header) 


00013900-00000000-00000000-00000011-11111111-1100 


PTSE Request Count 1 
PTSE Identifier 0 


specifying a routing topology. 


Header: Packet Type 


IG: 


Dunn & Martin 


Packet Length 

Protocol Version 

Newest Version Supported 
Oldest Version Supported 
Reserved 

Initialize (I)Bit 


More (M)Bit 

Master (MS)Bit 

Reserved 

Reserved 

DS Sequence Number 
Information Group Type 
Information Group Length 
Originating Node ID 


4 
6 
1 
1 
0 
0 
1 


60 


(DATABASE SUMMARY) 


(during init. 
process) 


of DB syn 


(PTSEs to summarize) 


(both nodes) 


(Nodal PTSE Summaries) 


00013900-00000000-00000000-00000011-11111111-1100 
Originating Node’s Peer Group 00000000-00000000-00000000- 


Reserved 0 
PTSE Summary Count 1 
PTSE Type 0 
Reserved 0 
PTSE Identifier 0 
PTSE Sequence Number 0 
PTSE Checksum 0 
PTSE Remaining Lifetime 0 

Informational 
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Header: Pack 


IG: 


IG: 
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Update, specifying a change in the routing topology. 


et Type 

Packet Length 9 
Protocol Version 

Newest Version Supported 
Oldest Version Supported 
Reserved 

Originating Node ID 


O: OHP DN 


(PTSP) 


00013900-00000000-00000000-00000011-11111111-1100 
00000000-00000000-00000000- 


Originating Node’s Peer Group 


Information Group Type 64 
Information Group Length 52 
PTSE Type 0 
Reserved 0 
PTSE Identifier 0 
PTSE Sequence Number 0 
PTSE Checksum 42252 


PTSE Remaining Lifetime 3600 
Information Group Type 224 


Information Group Length 32 


VP Capability Flag 1 
Reserved 0 
Reserved 0 
Port ID 0 
Scope of Advertisement 96 
Address Information Length 14 
Address Information Count 1 
Prefix Length 13 


0001 
(PTSE) 


(Internal Reachable ATM 


Addresses) 


(VPCs supported) 


Reachable Address Prefix 39000000-00000000-00000000-01 


Informational 
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